Software-update: OpenZFS 2.2.11 / 2.3.9 / 2.4.4

OpenZFS logoHet opensource zfs-bestandssysteem is 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 changelog voor versie 2.2.11 kan hier worden gevonden, voor versie 2.3.8 staat het hier en in versie 2.4.4 zijn de volgende veranderingen en verbeteringen aangebracht:

Supported Platforms
  • Linux: compatible with 4.18 - 7.2 kernels
  • FreeBSD: compatible with releases starting from 13.3+, 14.0+
Changes
  • [zfs-2.4.4] Add 'capsh' to commands.cfg
  • ZTS: device access tests #18960
  • vdev_disk: use calling cred to check for device access #18960
  • vdev_file: use calling cred to check for device access #18960
  • zfs_file_open: add cred arg, use it to check access #18960
  • vdev_open: pass credential to check for permission to open device #18960
  • secpolicy_zfs: add a note about the power of CAP_SYS_ADMIN #18959
  • secpolicy_sys_config: only permit a global zone credential #18959
  • secpolicy_zinject: only permit a global zone credential #18959
  • secpolicy_nfs: remove, not used #18959
  • ZTS: test secpolicy_zinject correctly limits namespace access #18959
  • ZTS: test secpolicy_sys_config correctly limits namespace access #18959
  • config: detect idmap method via generic_permission test #18769
  • mmp: tell a failed uberblock claim apart from remote activity #18892
  • ZTS: add coverage for zhack mmp reclaim #18892
  • zhack: add "mmp reclaim" to recover a pool stranded by MMP #18892
  • Make systemd-udev-settle optional for the import units #18832
  • Linux 7.2 compat: META #18941
  • Fix negative time overflows in DDT pruning #18886
  • nvpair: i_get_value_size() string array handling tweak #18877
  • nvpair: Improve native handling of unterminated strings #18876
  • CodeQL: Flag implicit compare-then-assign in branch conditions #18899
  • Linux 5.19/6.17: handle differences in how to flush delay workqueue #18847
  • Linux 6.3: follow_down() gains flags arg #18847
  • Linux 6.18 compat: vfs_parse_fs_string() takes 3 args #18847
  • nvpair: Fix operator precedence #18874
  • ZTS: don't read a command's exit status as a missing binary #18726 #18882
  • build: Fix release detection when build dir is not source dir #18891
  • CI: don't fail a passing job when a log reader has already exited #18885
  • CI: publish the per-VM test counter atomically #18885
  • man: zvol_request_sync is not ignored under blk-mq #18887
  • libzfs: don't read a dataset handle after closing it in resume send #18870 #18883
  • ZTS: add coverage for the MMP claim on a degraded mirror #18855
  • mmp: do not require writes to mirror legs the config marks absent #18855
  • libzfs: String trimming should not operate out of bounds #18868
  • libzfs: don't truncate a resolved vdev path in zpool_vdev_name() #18851 #18871
  • libzfs: Do not call munmap() when mmap() fails #18869
  • Add missing checks to zfs_clone_range_replay() #18867
  • Fix DMU bonus hold leak on I/O error #18865
  • zfs: fix stale POSIX ACL cache after rollback #18837
  • zed: let autoexpand see capacity changes on partitioned disks #12505 #18833
  • zpool export: return EBUSY when zvol minors are in use #18841
  • ZTS: make file_check actually compare the resume test results #18834
  • ZTS: save ZAP_MICRO_MAX_SIZE before the large microzap tests change it #18834
  • dmu_recv: Avoid potential null deref #18848
  • DDT: Fix several bugs in pruning #18838
  • cstyle: better tolerance for struct literals
  • libspl: Implement VERIFY_IMPLY and VERIFY_EQUIV #18822
  • mmp: skip non-writeable vdevs during activity check #18823 #18835
  • zdb: output refcounts from verify_spacemap_refcounts() #18809
  • L2ARC: bound the rebuild by the write hand on a first sweep #3114 #3400 #5583 #10224 #12779 #18827
  • ZTS: make zpool_iostat_interval_all teardown deterministic #18273 #18776
  • libzfs: fallback VDEV_UPATH to VDEV_PATH for non-DM devices #18439 #18802
  • Fix reads for blocks freed after being cloned #18421 #18724
  • Rate limit Direct I/O verify zevents #18795
  • CI: Update Alpine Linux runner to 3.24.1 #18790
  • Remove libuutil from the pull request template and fix headings #18791
  • ZTS: fix zpool_initialize_multiple_pools suspend race #18777
  • CI: Fix race caused by shared ctr file updates #18778
  • zpl_inode: remove zpl_rename no-flags variants #18769
  • ZTS: stop zpool_initialize tests racing initialize to completion #11948 #17311 #18771
  • ZTS: migration/setup: clear stale zfs_member label before new_fs #18492 #18753
  • Fix receive of split large blocks with a short trailing chunk #18749
  • Fix receive -x according to comment #18737 #18738
  • Add SECURITY.md policy file #18766
  • linux: batch DMU reads of non-resident pages in mappedread() #16031 #18741
  • Linux: fix zfs_write() infinite loop on unfaultable buffer #17129 #18740
  • build: Fix for building dist target outside of project root #18744
  • ZTS: ctime_001_pos increase tolerance #18733
  • libzfs: fix MS_CRYPT/MS_OVERLAY collision with umount2(2) flags #18713
  • Fix insufficient locking in dedup verify #17960 #18712 #18720
  • zpl_ctldir: remove comments describing ancient kernel behaviour #18722
  • Linux 7.2: zpl_super: convert to sget_fc() #18677
  • linux/abd: remove BIO support functions #18719
  • Using net/cloud-init to unpin specific python #18717
  • linux: handle mmap read beyond file size #18715
  • Fix race between device removal completion and pool export #18657
  • CI: Increase default watchdog NMI timeout on Linux #18704
  • ddt_log: Fix refcount tagging for begin/commit #18706
  • Update mtime/ctime when fallocate grows a file #18573
  • honor file argument in file_wait_event #18700
  • README: update supported FreeBSD release to 15.1 #18696
  • Clean up embedded slog metaslab across txgs #18693
  • initramfs-zfs should not try to copy directories #18582 #18686
  • CI: Re-allow workflow_dispatch on zfs-qemu #18680
  • zfs_ioctl: fix EBUSY race between quota queries and mount #18611
  • Fix handling of _PC_HAS_HIDDENSYSTEM for FreeBSD #18688
  • Linux 7.1 compat: META (#18682)
  • Update our CI runners to the newest FreeBSD 15.1 RELEASE (#18667)
  • CI: Have zfs-build-packages workflow build tarballs on Alma (#18662)
  • arc: add a few invariant checks in release builds #18840
  • zbookmark_compare: handle "marker" bookmarks with negative levels #14777 #18652
  • delegate: add 'send:encrypted' permission #18673
  • zfs_secpolicy_send: lift checks to common function for both #18673
  • ZTS: delegate: test send:encrypted #18673
  • ZTS: delegate: check send permissions on encrypted datasets #18673
  • ZTS: delegate: add encryption option for test fixture datasets #18673
  • ZTS: remove send_delegation tests #18672
  • ZTS: delegate: add test for send sub-permissions #18672
  • ZTS: statx_dioalign.ksh update to stride_dd #18547
  • ZTS: Pass dec instead of hex to mknod #18547
  • zio_ddt_write: compute have_dvas after taking dde_io_lock #18366 #18544
  • freebsd: set mnt_time on the rootfs at mountroot time
  • Add dbrrd_latest_time() to grab the latest timestamp in the db
  • Constify some rrd_*() functions

OpenZFS

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

Door Bart van Klaveren

Downloads en Best Buy Guide

22-08-2026 • 12:00

11

Bron: OpenZFS

Reacties (11)

Sorteer op:

Weergave:

Steeds meer volwassen. Zal HW met TB gaan verzamelen om een DAS te gaan bouwen voor een MAC. Ervaringen?
Hier gaat het om het pure filesysteem. Voor een zelfbouw nas (of zelfbouw das) zou ik eerder kiezen voor een nas-gebaseerde distributie.

En voor het filesysteem: naast (open-) Zfs is er ook btrfs, dat biedt op een vergelijkbare manier vergelijkbare faciliteiten. Onder bsd heb ik geen idee wat de status van beide filesystemen in bsd is. Voor linux heb ik het idee dat btrfs in linux beter/breder wordt ondersteunt. Er zijn zelfs distributies die er mee installeren.

[toevoeging]: Beide filesystemen hebben nogal geheugen honger: ze willen graag veel geheugen omdat ze een redelijk uitgebreide administratie hebben.

[Reactie gewijzigd door beerse op 22 augustus 2026 14:15]

ZFS zal onder in ieder geval FreeBSD vast prima werken omdat "ze" intussen "allemaal" OpenZFS gebruiken. Maar Mac OS is natuurlijk weer een eigen verhaal (ondanks een BSD root). Maar volgens mij is er ook een "fork" van OpenZFS voor Mac OS. Waarbij diegene ook gewoon samenwerkt met de OpenZFS devs en evt ook aankaart van "ik loop tegen problemen aan" of andersom juist proactief wordt gevraagd van "werkt dit ook voor jou op Mac?".

Btrfs en stabiel..., weet ik ook niet of dat intussen zo is? Volgens mij werd het gebruik van een setup met parity disks (traditioneel RAID5 / RAID6, bij ZFS RAIDZ1 / RAIDZ2 / RAIDZ3) sterk afgeraden omdat dat dus echt niet stabiel was en (te) vaak tot corruptie leide. En ik meen dat btrfs ook nog wel eens problemen heeft met unclean shutdowns? Dat die daarna corrupt is en alleen via omwegen te herstellen is. Iets dat natuurlijk ook niet zou moeten mogen (zeker voor een journaling filesystem).
Met dat zfs ooit bij Sun op Solaris is begonnen en dat Solaris een bsd-afgeleide is, kan ik mij voorstellen dat zfs op bsd wel aardig uit zou kunnen komen. Tel dat bij de info op de zfs wikipedia pagina: ja, zfs en bsd-unix komen goed bij elkaar.

Van btrfs heb ik ervaren dat SuSE er standaard op installeert. Zij hebben er dus wel vertrouwen in. Volgens mij zijn er meer linux distributies die dat doen of in ieder geval aanbieden. Aan de andere kant, het lijkt dat RedHat ooit wel iets met btrfs heeft gedaan maar nu niet meer.

Uiteindelijk zie ik dat oralce in beide kampen zit. Wat dat voor impact heeft weet ik niet. Wel weet ik dat oracle en opensource niet altijd even goede vrienden zijn: zfs onder linux is immers openzfs.
In het begin (2006-2010 zo uit mijn hoofd) van ZFS liep ZFS voor op Solaris en FreeBSD. Toen kreeg een Orakel een dode Zon, weg development. OpenZFS (ZFS on Linux) kreeg feature parity, en ging eroverheen. Uiteindelijk draait nu, behalve Solaris, alles OpenZFS. MacOS heeft een port (maar APFS heeft ook mooie featureset, en native), FreeBSD idem, en Linux natuurlijk ook. Er is zelfs een Windows port van. Al heb je van btrfs ook een port voor Windows.
Btrfs heeft nog steeds een nasty bug in raid5. Absoluut af te raden, behalve voor raid0, raid1, jbod.

Ook heeft de GP het over DAS voor een Mac. Btrfs werkt niet op een Mac, OpenZFS wel. Mac heeft echter native APFS.

Mac heeft slechte throughput op veel kleine bestandjes.

Ik zou voor een NAS gaan, en dan TB naar 10 gbit (liefst fiber) nemen van bijvoorbeeld Sonnet.

[Reactie gewijzigd door Jerie op 22 augustus 2026 14:40]

Wat voor nasty bug bedoel je?

Mijn synology draait al bijna 10 jaar met btrfs + raid5.
De native implementatie. Synology gebruikt mdadm, dan heb je van die bug geen last. Hoe snel gaat een scrub bij jou?

https://raidsize.com/blog/en/btrfs-raid-5-6-issues

Hoe dan ook zul je iets moeten doen met BBU of UPS of PLP. Ik heb mijn ZFS log en cache op een NVMe met PLP. Die NVMe (ik heb er 2x in RAID1) is nu helaas reteduur.

[Reactie gewijzigd door Jerie op 23 augustus 2026 02:21]

Jep, ze verbruiken RAM maar dat heeft een aantal voordelen (handig als storage in bv proxmox)
- Erg snelle snapshots
- Dataintegriteit
- Compressie (zstd)
- Geen classieke raid controller nodig
Gebruik ZFS al sinds de eerste introductie op FreeBSD....
Nog nooit een filesysteem verloren. Altijd al mega stabiel geweest.
Op papier heeft BtrFS zelfs meer features, maar toen ik die probeerde was het de ene crash na de andere...
Moet inderdaad wel rekening houden met een aantal dingen als je dit echt serieus neemt:
  • geen controllers die RAID, battery-backup, etc doen.
    Meesten hiervan liegen tegen het OS
  • Gebruik een moederbord dat ECC geheugen snapt, en gebruik ECC
    Anders loop je kans dat er toch fouten in het FS geschreven worden.
  • Gebruik geen disks met Shingled Magnetic Recording (SMR).
  • In tegenstelling wat hier wordt gesuggereerd is het niet perse extreem geheugen hongerig, maar als je je ook veel applicaties op de server wilt draaien, is wat meer geheugen best nuttig.
Wil je een appliance ready to go:
TrueNAS

[Reactie gewijzigd door wjwithagen op 22 augustus 2026 21:22]

Met een oude raid kaart met IT firmware, kan je met goedkope HDD en een zwikje SSD's toch wat leuks bouwen.

Zo heb ik onlangs nog met ZFS + ZRAID een volume gemaakt van goedkope WD Blue HDD, DDR3 ECC (genoeg voor ZFS ARC en goed voor de portemonnee) en een aantal SSD voor L2ARC/SLOG/Special. Voeg daar een leuke oude Xeon aan toe en je hebt een leuk bakje die met beetje load niet al teveel stroom trekt.

ARC = RAM-cache
L2ARC (cache) voor SSD-cache na ARC
SLOG (log) voor Snelle ZIL voor sync writes
Special vdev voor Metadata + optioneel kleine blocks
Data vdevs voor je uiteindelijke data op de HDD's

Om te kunnen reageren moet je ingelogd zijn