Software-update: OpenZFS 2.3.0

Het opensource zfs-bestandssysteem werd oorspronkelijk door Sun ontwikkeld voor Solaris, maar in 2013 heeft een aantal ontwikkelaars OpenZFS opgericht om de verdere ontwikkeling te waarborgen. Het bestandssysteem wordt momenteel officieel ondersteund op Linux en FreeBSD. Het bevat onder andere methodes om datacorruptie in zowel de data als de metadata te voorkomen, biedt dataredundantie via RAID-Z en bespaart ruimte door de data transparant te comprimeren. Voor meer informatie verwijzen we jullie door naar de OpenZFS-website. De ontwikkelaars hebben versie 2.3.0 uitgebracht en hierin zijn de volgende veranderingen en verbeteringen aangebracht:

Key Features in OpenZFS 2.3.0:

• RAIDZ Expansion (#15022): Add new devices to an existing RAIDZ pool, increasing storage capacity without downtime.
• Fast Dedup (#15896): A major performance upgrade to the original OpenZFS deduplication functionality.
• Direct IO (#10018): Allows bypassing the ARC for reads/writes, improving performance in scenarios like NVMe devices where caching may hinder efficiency.
• JSON (#16217): Optional JSON output for the most used commands.
• Long names (#15921): Support for file and directory names up to 1023 characters.
• Bug Fixes: A series of critical bug fixes addressing issues reported in previous versions.
• Numerous performance improvements throughout the code base.
• Supported Platforms:
  • Linux kernels 4.18 - 6.12,
  • FreeBSD releases 13.3, 14.0 - 14.2.

Additional Information:

• Documentation - OpenZFS documentation for Linux and FreeBSD.
• Change log - Complete v2.2.0 - v2.3.0 change log

Versienummer	2.3.0
Releasestatus	Final
Besturingssystemen	Linux, BSD
Website	OpenZFS
Download	https://github.com/openzfs/zfs/releases/tag/zfs-2.3.0
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (18)

[GorgeousMetal]

RAIDZ Expansion lijkt me erg fijn. Maar gaat dat alleen over toevoegen van harddisk aan bestaande pool of kan je Z-level (bijvoorbeeld van Z1 naar Z2) ook aanpassen?

Edit: Heb even #15022 bekeken en lees:

"This feature allows disks to be added one at a time to a RAID-Z group, expanding its capacity incrementally. This feature is especially useful for small pools (typically with only one RAID-Z group), where there isn't sufficient hardware to add capacity by adding a whole new RAID-Z group (typically doubling the number of disks)."

Dus alleen harddisks toevoegen aan bestaande pool en niet veranderen van level.

[Reactie gewijzigd door GorgeousMetal op 16 januari 2025 13:57]

[Blommie01]

Zeker de RAID-Z Expension functie is zeer welkom. Ben benieuwd hoe goed dit werkt.

[squaddie]

Een groot verschil tussen ZFS expansion en andere raid expansion is dat bij ZFS de data en parity ongewijzigd blijft, alleen nieuwe data krijgt de nieuwe stripe. Overigens kan een (deel van de) stripe verplaatst (middels CoW) worden naar nieuwe locatie bij de uitbreiding. Het voordeel is dat ZFS niets met je data en de parity doet en bij een mogelijk incident tijdens de uitbreiding geen risico voor je data inhoud. Het nadeel is dat je niet maximaal profiteert van de uitbreiding tenzij je zelf bestaande data opnieuw wegschrijft.

Concreet: Een vier disk raidz2 verliest 50 procent van de ruwe ruimte aan parity, wanneer je deze uitbreidt met een disk zal alle aanwezige data de 50 procent ruimte verlies behouden en alleen nieuwe data krijgt de 40 procent parity verlies.

[Arjan A]

RAIDZ Expansion (#15022): Add new devices to an existing RAIDZ pool, increasing storage capacity without downtime.

Kijk, dit maakt het toch een stuk interessanter om ZFS te gaan gebruiken! Eigenlijk verbaast het me dat het zo lang heeft geduurd voor deze feature erin kwam. Evenals de long names...

[Llopigat]

Het is doordat ZFS eigenlijk bedoeld was voor grote datacenters. Daar kan je net zo goed gewoon de hele vdev migreren naar een nieuwe grotere (en zfs send/receive is daar heel handig voor). Als thuisgebruiker heb je natuurlijk veel minder reserve capaciteit.

Let wel dat het nog steeds niet mogelijk is om devices te verwijderen uit een RAIDZ pool, zelfs niet als je meer dan genoeg ruimte hebt. Dus als je bijvoorbeeld van 5 naar 6 drives gaat in je vdev, dan kan je nooit meer terug.

Upgraden van capaciteit van de drives (dus niet het aantal maar de grootte) kon trouwens altijd al. Je kon ze een voor een vervangen door een grotere, dan resilveren en na het vervangen van de laatste drive was de nieuwe capaciteit beschikbaar.

Ik draai ZFS op root en het is een geweldig filesystem. Snapshots van je hele systeem zijn super als er wat misgaat, en ik draai elke paar dagen een automatische scrub om te herkennen of er problemen zijn met mijn drive.

[Reactie gewijzigd door Llopigat op 16 januari 2025 13:53]

[Jerie]

Ik vind het eigenlijk ook voor thuisgebruik niet enorm boeiend. De reden is dat je toch al backups moet hebben. Met je backup (waarvan er eentje onsite dient te zijn), kun je vervolgens de data naar een nieuwe array zetten. Zoals je zegt: zfs send/receive is daar heel handig voor.

Het grootste nadeel van ZFS is m.i. de increased power usage. En juist voor thuisgebruik is dat m.i. belangrijk. Iedere paar dagen een scrub vind ik lichtelijk overdreven. Wel doe ik voor ik incrementele backup maak (wekelijks) eerst een scrub (ook wekelijks).

[Llopigat]

Ik vind het juist super. Ik maak geautomatiseerd elke dag een snapshot. Dan kan ik snel terugrollen indien nodig. Snapshot maken gaat instant.

En de scrub doe ik nu elke nacht. Het duurt toch maar 10 minuten. Zfs trim ook.

En ja backups heb ik ook maar die maak ik lang niet zo vaak.

[Jerie]

Ja, maar daar heb je geen ZFS voor nodig. NixOS kan dat bijvoorbeeld ook. Andere CoW filesystems ook.

Een scrub van een NVMe gaat inderdaad snel.

En ja backups heb ik ook maar die maak ik lang niet zo vaak.

Dat is dan je probleem. Je kijkt regelmatig of je data nog intact is. Maar als dat niet zo is, heb je geen plan.

De meeste thuisgebruikers hebben eigenlijk helemaal geen RAID nodig. Want eventuele downtime zouden ze voor lief nemen, en een hot of cold spare hebben ze ook niet op lokatie. Wat zij nodig hebben, is adequate backups. Offsite en onsite.

[Reactie gewijzigd door Jerie op 16 januari 2025 15:29]

[Llopigat]

Nouja met NixOS heb je iets anders, daar kan je makkelijk je hele systeem mee herconfigureren op basis van 1 tekstfile. Maar dat is geen snapshot. Je gebruikersdata wordt daarmee bijvoorbeeld niet teruggedraaid. Maar ik wil sowieso niet zo'n declarative systeem.

En ja met andere CoW filesystems kan je hetzelfde, dat is waar. De meesten hebben ook snapshots (zoals btrfs). Maar ik heb liever ZFS.

En RAID gebruik ik sowieso niet. Ik heb het op mijn dagelijkse computer en die heeft maar een drive. Je hebt geen array nodig om voordeel te hebben van ZFS. Ik vind de toolset ervan handig en ik gebruik het al zeker 15 jaar en heb er nooit problemen mee gehad.

Dat is dan je probleem. Je kijkt regelmatig of je data nog intact is. Maar als dat niet zo is, heb je geen plan.

Ja maar ik ga niet dagelijks backuppen. Dat wil ik ook helemaal niet. Daar zijn snapshots ideaal voor.

[Reactie gewijzigd door Llopigat op 16 januari 2025 17:21]

[Jerie]

Met Arch had ik net zoiets, maar dan dus met ZFS en zonder NixOS. Werden constant snapshots gemaakt, kost ook nagenoeg niets want CoW. Hoewel dus wel op een gegeven moment je zoveel snapshots kunt hebben dat list enzo te lang duurt

Met 1 disk zou ik syncoid gebruiken (als sanoid), en dan syncoid af en toe even laten backuppen. Met --sendoption=w hou je je data versleuteld met ZFS native encryption. Via een veilige verbinding zou je met mbuffer kunnen werken. Zo gebruik ik al Wireguard, dus hoef niet ook nog 'ns SSH over Wireguard. Je zou ook nog meerdere kopieën van (bepaalde) data op je NVMe kunnen zetten. Probleem is wel dat je je disk niet te vol mag laten lopen want dat vindt ZFS niet leuk i.v.m. fragmentatie (andere filesystems ook niet maar ZFS des te meer).

[d3vlin]

Pas op met de combinatie zfs native encryption en raw (-w) send/receive.
https://github.com/openzfs/openzfs-docs/issues/494
Het concept is fantastisch, maar in sommige gevallen blijkbaar fragiel.

[RobertMe]

Ik vind het eigenlijk ook voor thuisgebruik niet enorm boeiend. De reden is dat je toch al backups moet hebben. Met je backup (waarvan er eentje onsite dient te zijn), kun je vervolgens de data naar een nieuwe array zetten. Zoals je zegt: zfs send/receive is daar heel handig voor.

Maar niet alles is interessant om te backuppen. Ik maak bv geen backup van de Linux ISOs. Maar bij een migratie naar een grotere pool zou ik ze wel weer willen behouden. Anderzijds kun je natuurlijk ook de minder belangrijke ISOs verwijderen zodat je nog plek genoeg hebt op de bestaande pool .

Daarnaast kun je (redelijk) live overstappen naar een grotere pool (dus tijdelijk "dubbele of meer aantal disks"), of de bestaande pool groter maken (vdev toevoegen aan bestaande pool). De bestaande pool vernietigen, en een nieuwe pool aanmaken met meer vdevs (uit de oude pool + nieuwe), en dan herstellen vanaf een backup brengt (veel/lange!) downtime met zich mee. Dat is dus ook niet ideaal.

[Jerie]

Mijn OS images ('Linux ISOs') worden gedeeld middels netbootxyz. Ze staan op een USB stick. Als ik die USB stick nodig heb, dan haal ik hem er gewoon uit. Maar eigenlijk is ook dat niet meer nodig sinds ik glasvezel heb.

De bestaande pool vernietigen, en een nieuwe pool aanmaken met meer vdevs (uit de oude pool + nieuwe), en dan herstellen vanaf een backup brengt (veel/lange!) downtime met zich mee. Dat is dus ook niet ideaal.

Voor thuisgebruikers is HA helemaal geen eis, die kunnen prima met downtime overweg. Die hebben ook eigenlijk geen RAID nodig. Kijk, ik heb het wel, maar heb ik het echt nodig? Nee. Wel nodig: backups.

[nero355]

Iedere paar dagen een scrub vind ik lichtelijk overdreven.

Dat kan ook prima 1 keer per maand of zo...

Het is maar net wat voor data het is en wat je ermee doet, maar zo te zien leg jij jezelf een hoop "Moet, moet, moet" dingen op waardoor het inderdaad allemaal heel gauw een vervelende draai krijgt, terwijl dat nergens voor nodig is

Stroomgebruik is ook zoiets : Niemand zegt dat die DIY NAS de hele tijd aan moet staan!
Kan ook prima alleen op het moment dat je daadwerkelijk wat ermee gaat doen

[Gijs007]

Hoger energieverbruik van ZFS is inderdaad een ding. Ik las ook dat de individuele disks in een pool niet downspinnen: https://www.reddit.com/r/.../1b20dnt/comment/kslcl38/

In de ideale wereld heb je een pool met een cache SSD, waarop zowel de reads als writes plaatsvinden, waarbij het HDD gedeelte van de pool kan downspinnen. Om zo het energieverbruik verder terug te dringen.

Ben verder wel benieuwd wanneer deze versie van ZFS wordt opgenomen in bijv. Proxmox.

[woutersamaey]

Wow, klinkt als een mooie update!

[Tim AtSharp]

Inderdaad, expansion feature is iets waar ik al vele jaren op wacht. Nu afwachten wanneer het in de gangbare producten / setups komt ( truenas bv)

[valhalla77]

voor referentie, dit is iets wat iXSystems heeft gesponsord en drijvende kracht achter RaidZ expansion was. Voor diegene die niet weten wie IXSystems is, het zijn de makers van TrueNAS. Het is mooi om te zien dat met alle enshitification die we tegewoordig zien, dat er toch nog een hoop bedrijven zijn die maatschappelijk belang hoog in het vandel hebben staan.

[Reactie gewijzigd door valhalla77 op 16 januari 2025 14:04]