Software-update: OpenZFS 2.3.3

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 enkele dagen geleden versie 2.3.3 uitgebracht en hierin zijn de volgende veranderingen en verbeteringen aangebracht:

Supported Platforms

• Linux: compatible with 4.18 - 6.15 kernels
• FreeBSD: compatible with releases starting from 13.3+, 14.0+

Changes

• Tag zfs-2.3.3
• Linux 6.15 compat: META #17393
• Fix mixed-use-of-spaces-and-tabs rpmlint warning #17461
• ioctl: remove FICLONE/FICLONERANGE/FIDEDUPERANGE compat #17308
• Relax zfs_vnops_read_chunk_size limitations #17415
• dmu_traverse: remove 'ignore_hole_birth' tunable alias #17376
• ARC: parallel eviction #16486
• During pool export flush the ARC asynchronously #16215
• CI: Automate some GitHub PR status labels manipulations #16721
• FreeBSD: zfs_putpages: don't undirty pages until after write completes #17445
• zfs_log_write: only put the callback on the last itx #17445
• zpl_sync_fs: work around kernels that ignore sync_fs errors #17420
• zfs_sync: return error when pool suspends #17420
• zfs_sync: remove support for impossible scenarios #17420
• zts: test syncfs() behaviour when pool suspends #17420
• Improve block cloning transactions accounting #17431
• Reduce zfs_dmu_offset_next_sync penalty #17434
• Make TX abort after assign safer #17438
• Allow zero compression if dedup is enabled #17435
• ZTS: Enable io_uring on CentOS Stream 9 and 10 also #17447
• Linux build: silence objtool warnings #17410
• CI: Retire Fedora 40 builder #17408
• ZTS: Enable io_uring support on el9/el10 #17397
• ZTS: Add AlmaLinux 10 #17397
• abd_os: move headers from libzpool to libspl #16940 #17390 #17394
• Set spa_final_txg in spa_unload() #17395
• zpool: clarify ZPOOL_STATUS_REMOVED_DEV status message #17400
• vdev: skip faulting disks pending removal #17400
• CI: Retire Ubuntu 20.04 builder #17403
• linux/zvol_os: don't try to set disk ops if alloc fails #17396
• Linux build: always use objtool
• Reviewed-by: Tony Hutter [e-mail] #17401 #17364
• tunables: fix spelling #17377
• tunables: remove __check_old_set_param workaround #17377
• tunables: remove unused param get/set aliases #17377
• tunables: use Linux ullong param ops for u64 #17377
• tunables: remove support for s64 tunables #17377
• tunables: remove direct use of module_param_cb #17377
• tunables: remove FreeBSD compat macros for Linux module params #17377
• tunables: ensure tunable and variable have same define gate #17377
• tunables: don't assert initialisation in impl getters #17377
• zfs_log: make zfs_immediate_write_sz uint #17377
• Only interrupt active disk I/Os in failmode=continue #17372
• zcp: get_prop: fix encryptionroot and encryption #17280
• ZVOL: Comment platform-specific empty functions bodies on FreeBSD side #17383
• Expose dataset encryption status via fast stat path #17368
• ZIL: Improve write log size accounting #17373
• ZTS: testing for leaked key mappings in encrypted non-raw send #17366
• Refactor man page and CLI help output per mandoc #17357
• Reformat cli help and man page to be in sync #16004 #17357
• Fix off-by-one bug in range tree code #17363
• Fix null dereference in spa_vdev_remove_cancel_sync() #17361
• Update 69-vdev.rules.in #17345
• lzc_ioctl_fd: add ZFS_IOC_TRACE envvar to enable ioctl tracing #17344
• lzc: move lzc_ioctl_fd() into lzc proper #17344
• libzfs: ensure all ioctl calls go through lzc_ioctl_fd() #17344
• Add Quality Assurance to pull request template #17354
• dmu_objset_hold_flags() should call dsl_dataset_rele_flags() on error #17353
• arcstat: prevent ZeroDivisionError when L2ARC becomes empty #17348
• Linux 6.2/6.15: del_timer_sync() renamed to timer_delete_sync() #17229
• Linux 6.15: mkdir now returns struct dentry * #17229
• icp: Use explicit_memset() exclusively in gcm_clear_ctx() #17343
• Fix 2 bugs in non-raw send with encryption #12014 #17340
• Cause zpool scan resume commands to get logged in history #17301
• ARC: Notify dbuf cache about target size reduction #17314
• Linux: Stop using NR_FILE_PAGES for ARC scaling #17334
• runners: Add option to install custom kernel on Fedora #17156
• vdev_id: symlinks creation for multipath disk partitions (#17331)
• AUTHORS/mailmap: update with new contributors
• update_authors: output possible mailmap additions
• For the moment, this needs to be done by a human, because update_authors
• update_authors: consider Signed-off-by trailers for committer idents
• test-runner: rework output dir construction #17167
• spa: clear checkpoint information during retry #17319
• linux/uio: remove "skip" offset for UIO_ITER #17298
• More aggressively assert that db_mtx protects db.db_data #17209
• FreeBSD: Use new SYSCTL_SIZEOF() #17309
• ARC: Avoid overflows in arc_evict_adj() (#17255)
• txg: generalise txg_wait_synced_sig() to txg_wait_synced_flags() (#17284)
• ZTS: Restore some delays in online_offline tests
• Fix race between resilver wait and offline/detach
• tests: fix S_IFMT undeclared at statx.c #17293 #17294
• ZTS: Stop zpool_status tests from spamming stdout (#17292)
• Fix double spares for failed vdev
• ZTS: Fix replacement/resilver_restart_001 on FreeBSD #16822 #17279
• Sort the blocking snapshots list #12751 (#17264)
• Double quote variables to prevent globbing and word splitting #17235
• cred: properly pass and test creds on other threads (#17273)
• ZTS: Optimize KSM on Linux and remove it for FreeBSD #17247
• zfs-rollback.8: fix typo in example number #17282
• ZTS: Use Ubuntu default url for cloud-image #17278
• ZTS: Make zvol_stress write some more #17270
• ZTS: Reduce extra caching in pool_checkpoint (#17268)
• Support using llvm-libunwind #17230
• Export correct symbols for Lustre Direct I/O #17256
• Add more descriptive destroy error message
• ZTS: Fix 256MB file leak in zed_cksum_reported
• ZTS: Update FreeBSD version numbers
• ZTS: Remove fixed sleeps from slog_006_pos
• ZTS: Polish online_offline tests
• ZTS: Remove ashift setting from dedup_quota test (#17250)
• Cleanup VERIFY() macros (#17163)
• vdev_to_nvlist_iter: ignore draid parameters when matching names (#17228)
• Improve L2 caching control for prefetched indirects #17204
• ZTS: Remove TXG_TIMEOUT from dedup_quota test (#17150)
• Prefer embedded blocks to dedup #17113
• ZAP: Reduce leaf array and free chunks fragmentation #16766

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

Reacties (18)

[szjoin]

Ik heb net een schijfje gekocht voor backup doeleinden (foto's video's).

Ga toch eens ZFS overwegen ipv de standaard ext4 oplossing.

[niqck]

Hangt er van af wat je van ZFS verwacht. ZFS is een combinatie van Filesystem en Volume Management. Hoewel je het op een single-disk kan gebruiken, komt de kracht pas naar boven wanneer je die in RAID gaat gebruiken. ZFS block checksums kunnen silent corruption detecteren en herstellen aan de hand van de RAID-copy.

Met meer dan 20 jaar ervaring met ZFS (gestart op beta's van Solaris 10) heb ik nog geen bit data verloren. Enige keer dat ik me herinner dat een klant datacorruptie had, was toen ze een filesystem vanaf SAN geforceerd mounten op 2 servers in een cluster. Gegarandeerd koekenbak :

[vanaalten]

ZFS op single disk heb ik hier wel. Ik ben zeker geen expert op ZFS gebied, kan het dus helemaal fout hebben, maar volgens mij heeft het toch wel duidelijk voordelen boven ext4: checksum over je data. Weliswaar geen automatische error-correctie, maar wel daarmee error-detectie. Dus als je backup-strategie verder in orde is kan je na een error op je filesystem in elk geval correcte data van je backup terughalen.

Daarnaast heeft ZFS de mogelijkheid van snapshots - vind ik ook wel wat waard, om dat bestand dat ik vorige week had gewist nog even van een maand eerder terug te halen.

[Sandor_Clegane]

Je kan instellen dat het op een enkele schijf meerdere kopieën bijhoudt. Scheelt als het een sector is die de geest geeft.

[Jay-v]

Snapshots, ARC, Scrub. Ook handig met single disk.

[Stry]

Als snelheid niet je hoogste prio is, kan je je schijf opdelen in 6 partities, en daar een raidz1 van maken. geen redundancy maar wel automatische error correctie. Zo heb ik een paar bootdisks ingesteld. Het boeit me niet of ze kapot gaan, er staat toch geen belangrijke data op, maar heb ik wel snapshots en automatische correctie.

[The Zep Man]

Weliswaar geen automatische error-correctie, maar wel daarmee error-detectie.
(...)
Daarnaast heeft ZFS de mogelijkheid van snapshots

Dat heeft btrfs ook, en dat wordt met de kernel meegeleverd.

[niqck]

Ik zei ook niet dat het nutteloos was, enkel dat de grote kracht wanneer je naar RAID gaat. Ik heb mijn NAS al 2 keer ge-upgrade, alle disks vervangen door grotere, complete NAS vervangen en op 15 jaar nog geen bit data verloren, ondanks 3 defecte disks.

ZFS heeft heel veel leuke features die je ook in een hoop andere FS vindt, maar voor mij ligt de kracht echt in de eenvoud waarmee je alles kan beheren. Scrubs, snapshots, clones voor backup-transfers etc...

[foxhunt]

Ja, zou heb ik ooit een klant gehad die eerst zijn lvm volume ging verkleinen en daarna zijn filesystem, wat raar het is stuk :-)

[Jacco011]

Voor backups op één enkele HDD ben je beter af met XFS. XFS heeft betere performance voor grote bestanden en vraagt minder ressources van je CPU. Het schijnt ook beter bestand te zijn als de connectie per ongeluk verbreekt, vooral als je de HDD per externe USB gebruikt kan dat voorkomen.
ZFS is vooral interessant, als je het gebruikt in een pool in een NAS/server.
unRAID gebruikt ook XFS. Je kan deze XFS HDD dan met bestanden en al in een unRAID server stoppen.
Je enige voordeel met ZFS zou zijn, ist dat het bitrot kan detecteren, maar zonder een RAID of een andere backup ga je dit niet kunnen repareren.

[Reactie gewijzigd door Jacco011 op 24 juni 2025 17:35]

[_JGC_]

Nou heeft Redhat de afgelopen jaren heel veel verbouwd aan XFS, maar ik ben een oude gebruiker van XFS die het FS destijds behoorlijk beu was.

XFS is ooit door SGI ontworpen voor de betrouwbaarheid van SGI hardware. Stroomuitval? Dat ving SGI hardware gewoon op. Geheugencorruptie of bitrot? Moet je maar betrouwbare hardware kopen.

De keren dat ik een niet-te-booten server had met XFS als rootfs omdat na stroomuitval of een crash het filesystem niet meer wilde mounten, kernel panics omdat een bitje om was gevallen, bestanden die compleet genulld waren omdat ze open stonden terwijl je de stroom eruit trok, dat soort ellende... ik ben sindsdien Ext4 gaan gebruiken.

ZFS heeft compressie, snapshots, replicatie, ingebouwde RAID functionaliteit en vast nog wel een paar dingen die ik vergeten ben maar die niet aanwezig zijn in XFS.
XFS heeft dan weer fast block cloning wat benut wordt door software als VEEAM, maar OpenZFS 2.3.x heeft dat dus ook sindskort.

[Jacco011]

Mijn DIY movie server heeft Debian op een Ext4 SSD. Maar HDD met XFS. Het beste van beide werelden. Backups, bitrot detectie/reparatie en scrubbing loopt via SnapRAID. Dat werkt goed voor een Write Once Read Many (WORM).
Voor belangrijke bestanden heb ik een NAS met TrueNAS met OpenZFS en externe backup.

[beerse]

Vraag je af wat jouw eisen zijn aan dat backup schijfje. Zelf heb ik sommige backups bewust op een fat-filesysteem staan. Vooral omdat zo ongeveer elk systeem daar mee om kan gaan. De disk en de gegevens worden bewust bewaard om beschikbaar te zijn, niet om beveiligd te zijn tegen onvoorzien lezen door anderen. Met als grote voordeel van fat dat het geen gebruikers-rechten kent en daar dus niets mee fout kan gaan.

Aan de andere kant, als je de schijf buiten bereik wilt opslaan, waar anderen er mogelijk bij kunnen, dan wil je wel beveiliging en versleuteling. Dat kan uit het filesysteem komen. Het kan ook van de disk komen (bitlocker, veracrypt) en het kan ook puur op de bestanden staan.

Enneh, bedenk dat zowel ext4 als zfs een journaled filesysteem (kunnen) zijn. Daarmee zijn corrupte schrijf acties in de regel wel geadresseerd: Het systeem zal dat herkennen en kunnen oplossen. Dan moet dat wel netjes ingesteld zijn en ook netjes worden gebruikt.

[Matthijz98]

Ik ben vooral aan het wachten op ZFS anyraid: https://hexos.com/blog/introducing-zfs-anyraid-sponsored-by-eshtek zoek nog steeds een goede manier om schijven van verschillende grote samen te voegen.

[orvintax]

Hoeveel verschillende grootes heb je? Want als je meerdere schijven hebt van dezelfde grootte kun je er vdevs van maken en deze samen koppelen in een pool. Zo heb ik 2 x 4 schijven samen gebracht. Dit heeft overigens wel enige implicaties.

[Jacco011]

Voor bijv. een film/series server waar je meestal Write Once Read Many (WORM) hebt, kun je kijken naar SnapRAID. Heel flexibel met mixmatch. Echter is het dus geen live RAID.

[GorgeousMetal]

Ik gebruik ZFS al jaren op mijn NAS systemen en ben er erg tevreden over. Nog nooit problemen ondervonden. Mijn recente NAS gebruikt TrueNAS wat gebruik maakt van OpenZFS. Ik ben dan ook erg blij dat er actieve ontwikkeling is van OpenZFS. Het wordt elke keer weer beter.

[- peter -]

Ben nog altijd enthousiast over mijn 3x8GB ZFS op SSD.
Werkt helemaal top en met regelmatige scrubbing weet je dat t nog goed zit. Ben wel over op btrfs volumes als ik puur een mountpunt op een server wil met compressie zodat data van een bepaalde docker compressed word. Dan hoef je tenminste geen kernel modules te bouwen. Maar voor mijn data storage blijft t ZFS.