OpenZFS 2.2-rc5 Released With More Fixes & Linux 6.5 Compatibility

[phoronix]

Phoronix: OpenZFS 2.2-rc5 Released With More Fixes & Linux 6.5 Compatibility

The OpenZFS 2.2 release candidates are dragging on with the fifth test release having debuted on Saturday to provide some additional fixes and support for the Linux 6.5 stable kernel...

https://www.phoronix.com/news/OpenZFS-2.2-rc5-Released

[skeevy420]

57 fixes or changes between OpenZFS 2.2 rc4 and rc5. Damn, that must make OpenZFS one horribly buggy file system.

Ext4, on the other hand, has only had one fix between Linux 6.6 rc2 and rc5. Good, but not the best.

BTRFS, however, hasn't had a single fix or change since 6.6 rc2. That clearly makes it the best file system.

[timofonic]

57 fixes or changes between OpenZFS 2.2 rc4 and rc5. Damn, that must make OpenZFS one horribly buggy file system.

Ext4, on the other hand, has only had one fix between Linux 6.6 rc2 and rc5. Good, but not the best.

BTRFS, however, hasn't had a single fix or change since 6.6 rc2. That clearly makes it the best file system.

Sarcasm?

[skeevy420]

Sarcasm?

No. Not at all. After nearly 8 years of using OpenZFS and waiting on block cloning, reflinks, the one killer feature that BTRFS had over OpenZFS and made me jealous and envious, I'm just going to give it all up for BTRFS. It'll be, like, totally fun migrating all my case insensitive games to a case sensitive file system. Unzipping mods will be a hoot and a holler on BTRFS. Even better, I can't wait to pick one compressor for the entire drive while being given the opportunity to work on my memorization techniques since now I'll have to remember everything I set manually with chattr. It's even better because I get to do that with two separate pools split into more datasets than I care to count using multiple compression settings that BTRFS doesn't even support. With BTRFS, I can finally replace my pool's NVMe caching drive with, well, nothing because BTRFS is so great and optimized it doesn't need one. It's going to be so awesome and glorious going to BTRFS.

[AlanTuring69]

No. Not at all. After nearly 8 years of using OpenZFS and waiting on block cloning, reflinks, the one killer feature that BTRFS had over OpenZFS and made me jealous and envious, I'm just going to give it all up for BTRFS. It'll be, like, totally fun migrating all my case insensitive games to a case sensitive file system. Unzipping mods will be a hoot and a holler on BTRFS. Even better, I can't wait to pick one compressor for the entire drive while being given the opportunity to work on my memorization techniques since now I'll have to remember everything I set manually with chattr. It's even better because I get to do that with two separate pools split into more datasets than I care to count using multiple compression settings that BTRFS doesn't even support. With BTRFS, I can finally replace my pool's NVMe caching drive with, well, nothing because BTRFS is so great and optimized it doesn't need one. It's going to be so awesome and glorious going to BTRFS.

Everyone is always comparing and mixing and matching features but often times the fewer features, the better. What's faster, some obscure filesystem that has the audacity to call itself ZFS with a billion well-polished features or just dding the damn tarball onto the NVMe SSD? Completely asinine to even think about using ZFS.

[skeevy420]

Everyone is always comparing and mixing and matching features but often times the fewer features, the better. What's faster, some obscure filesystem that has the audacity to call itself ZFS with a billion well-polished features or just dding the damn tarball onto the NVMe SSD? Completely asinine to even think about using ZFS.

Sometimes there's just having too few features. Once you've used a file system with everything and the kitchen sink, using anything else is painful and difficult. It's impossible to replicate my simple gaming setup with any other file system because it uses case insensitivity and both Zstd and LZ4. With anything else I can only pick one. That's the Steam Deck compromise and why they picked both BTRFS and Ext4.

Extract some Skyrim mods on Linux and then you'll understand why Valve picked Ext4 with case insensitivity for the Steam Deck's game storage. I was doing that back in 2016 on OpenZFS with LZ4. These days I use Zstd:19 since that extremely high setting still writes faster than my ISP lets me download. Ironically, I decompress my mods to a very heavily compressed file system and I don't have to worry about /a and /A being two different places. There's no in-game lag because the prefix uses LZ4. Case insensitivity is one of those little things that you don't realize how great it is unless you actually use it and need it. I play Windows games, use Windows mods, and everything behaving like it does on Windows is a godsend. Being able to turn any odd directory into its own dataset to turn on or off COW features, set alternate compressors, set case handling, record size for databases and torrents, and a lot more is just damn handy once you get accustomed to it.

To put in bluntly, everything else just sucks once you get spoiled on OpenZFS.

[darkbasic]

Be careful with this issue if you plan to use zvols with the new zvol_use_blk_mq=1 in 2.2: https://github.com/openzfs/zfs/issues/15351