OpenZFS 2.1 Gets More Cleanups, Better Documentation Ahead Of Release

[phoronix]

Phoronix: OpenZFS 2.1 Gets More Cleanups, Better Documentation Ahead Of Release

The seventh release candidate of OpenZFS 2.1 is now available for testing while it looks like soon it will cross the finish line as the latest feature release for this open-source ZFS file-system implementation for Linux and FreeBSD systems...

https://www.phoronix.com/scan.php?page=news_item&px=OpenZFS-2.1-rc7-Released

[flower]

zfs... another case of "i would like to like it"
but it eats way to many iops and lacks to many features

well... that way my dm-integrity->mdadm raid->cryptsetup->lvm->ext4 setup keeps running for a few years. way faster, better supported (eg defrag, swap)

when i switch my nas to ssd i'll have a look again

[Chugworth]

zfs... another case of "i would like to like it"
but it eats way to many iops and lacks to many features

well... that way my dm-integrity->mdadm raid->cryptsetup->lvm->ext4 setup keeps running for a few years. way faster, better supported (eg defrag, swap)

when i switch my nas to ssd i'll have a look again

If you're talking about a NAS, then just stick a lot of memory in it and you won't even need swap or defrag. ZFS's heavy use of block caching makes defrag unimportant. You'll have RAID support as well as built-in encryption that can be applied to specific datasets, or have different encryption keys for different datasets. So your entire chain there could be replaced with one thing - ZFS.

As far as lack of features, I don't know what I would do without the ability to send/receive snapshots, and ZVOL's are extremely useful for virtualization.

[flower]

If you're talking about a NAS, then just stick a lot of memory in it and you won't even need swap or defrag. ZFS's heavy use of block caching makes defrag unimportant. You'll have RAID support as well as built-in encryption that can be applied to specific datasets, or have different encryption keys for different datasets. So your entire chain there could be replaced with one thing - ZFS.

As far as lack of features, I don't know what I would do without the ability to send/receive snapshots, and ZVOL's are extremely useful for virtualization.

my nas has 128GB ECC RAM
but with my 5400rpm drives seq read with zfs was down to 10mb/s after a short while.
i even tried it with a special vdev on a fast m2 ssd.

my setup still can saturate my 2.5gb/s link. without defrag. that m2 ssd now holds the integrity data in an zfs zvol though

[CommunityMember]

Last I knew, OpenZFS would not build on at least some ppc64le kernels as of 5.12 because the new (and now default as of 5.12) use of the improved spinlock code which is exported GPL-only.

[Chugworth]

my nas has 128GB ECC RAM
but with my 5400rpm drives seq read with zfs was down to 10mb/s after a short while.
i even tried it with a special vdev on a fast m2 ssd.

my setup still can saturate my 2.5gb/s link. without defrag. that m2 ssd now holds the integrity data in an zfs zvol though

10mb/s? I'm guessing you must be using SMR drives. They are known to work badly with ZFS.

[flower]

10mb/s? I'm guessing you must be using SMR drives. They are known to work badly with ZFS.

no, definitly not smr.
at start it was very good.
then i moved all files (around 4tb filled from 12tb nett total on a mirrored stripe) to another dataset which likely caused fragmentation (no way to check)

and from then it got worse.
mostly very big files which got extracted in parallel - which may caused frag as well.
but i am not the only one... 5400rpm drives are just too slow for zfs. saw some users on reddit with the same problem - and the suggestion was always the same -> get faster drives.

10mb/s was after two month.

but well i am happy with my dm-integrity/mdadm setup. i'll switch to zfs as soon as i can afford 16x2tb dc ssd.

EDIT: zpool iostat did show a huge iops count. and those 5400rpms just dont have many. so i am pretty sure about my analysis. they also where aligned correctly

[ryao]

zfs... another case of "i would like to like it"
but it eats way to many iops and lacks to many features

well... that way my dm-integrity->mdadm raid->cryptsetup->lvm->ext4 setup keeps running for a few years. way faster, better supported (eg defrag, swap)

when i switch my nas to ssd i'll have a look again

The IOPS penalty against MDRAID+XFS is about 15% when properly tuned according to tests that I did in 2016. Many would deem this to be a worthwhile tradeoff for the O(1) snapshot capability and background incremental send/recv that enable backups without penalizing active workloads. I suspect that the difference between a properly tuned ZFS and your setup is smaller than the one I measured against MDRAID+XFS in the past.

Fragmentation is a fairly minor issue with ZFS (and most POSIX filesystems), although it does hurt performance in certain workloads. You can do it via zfs send/recv if you really must defragment. Whether that is online or not depends on how much free space you have, although best results might be found offline (where you restore from backup). However, most people simply don't need it.

[ryao]

Last I knew, OpenZFS would not build on at least some ppc64le kernels as of 5.12 because the new (and now default as of 5.12) use of the improved spinlock code which is exported GPL-only.

There is an open issue for that:

https://github.com/openzfs/zfs/issues/11958

Canonical is asking if upstream would change the symbol export to retain compatibility.

[CommunityMember]

There is an open issue for that: https://github.com/openzfs/zfs/issues/11958

An issue was previously opened as: https://github.com/openzfs/zfs/issues/11172 but until 5.12 (with changes in some default configs) it was mostly unseen.

Canonical is asking if upstream would change the symbol export to retain compatibility.

Given that spinlocks are a rather common/fundamental thing for 3rd party modules to need either directly or indirectly, and realistically not all such modules are going to be GPL'd, it clearly is in the interest of module developers to see this get resolved by relaxing the GPL-only requirement for this specific use (if kernel spinlocks are now going to be off-limits, things get interesting). Time (and the authors willingness to change the license) will tell what approaches are going to be necessary for such 3rd part modules.