OpenZFS 2.3-rc4 Released With Linux 6.12 LTS Support

[phoronix]

Phoronix: OpenZFS 2.3-rc4 Released With Linux 6.12 LTS Support

Following the OpenZFS 2.2.7 stable point release earlier this week that brought Linux 6.12 LTS kernel compatibility along with various fixes, OpenZFS 2.3-rc4 is out today as the latest step toward the big OpenZFS 2.3 feature release...

https://www.phoronix.com/news/OpenZFS-2.3-rc4

[skeevy420]

Long names (#15921): Support for file and directory names up to 1023 characters.

8.3 file names and 255 characters ought to be enough for anybody.

[varikonniemi]

how many days until the next silent data corruption issue? Maybe all out of tree fanatics should stick with something that is in tree and does not suffer from such corruption issues. like bcachefs.

[pWe00Iri3e7Z9lHOX2Qx]

how many days until the next silent data corruption issue? Maybe all out of tree fanatics should stick with something that is in tree and does not suffer from such corruption issues. like bcachefs.

I know this is trolling, but the feature list for ZFS is enormous compared to bcachefs (as you'd expect given its age), including basic things like stable erasure coding. Tiered storage is the best feature from bcachefs not available in ZFS. But again, even super basic stuff that was supposed to be working in bcachefs when it first went into mainline, like mounting natively encrypted pools, didn't work. And there's a reasonable chance that bcachefs won't be in-tree much longer.

Also, even much simpler in-tree filesystems like ext4 had data corruption issues make it into production, on LTS kernel branches no less.

[Chugworth]

The changes that they've made to their data deduplication method sound like they're really polishing a turd. Constantly checking a table for duplicate blocks on every write sounds like a horrendous way to handle it. They should make a deduplication method that can work in the background or on a schedule and use block cloning rather than constantly maintaining some giant deduplication table.

[varikonniemi]

I know this is trolling, but the feature list for ZFS is enormous compared to bcachefs (as you'd expect given its age), including basic things like stable erasure coding. Tiered storage is the best feature from bcachefs not available in ZFS. But again, even super basic stuff that was supposed to be working in bcachefs when it first went into mainline, like mounting natively encrypted pools, didn't work. And there's a reasonable chance that bcachefs won't be in-tree much longer.

Also, even much simpler in-tree filesystems like ext4 had data corruption issues make it into production, on LTS kernel branches no less.

I support bcachefs because it's ways ahead of others in design, and especially because it's in tree. If it is kicked out, then i don't have a strong preference between it and zfs if everything else continues same.

[Espionage724]

how many days until the next silent data corruption issue? Maybe all out of tree fanatics should stick with something that is in tree and does not suffer from such corruption issues. like bcachefs.

Or, ext4

[mbod]

how many days until the next silent data corruption issue? Maybe all out of tree fanatics should stick with something that is in tree and does not suffer from such corruption issues. like bcachefs.

"in tree" is not a quality assurance. At least for out of tree you can decide if you want to upgrade your module to the newest version or if not. Sometimes it makes sense not to upgrade and wait to see if bugs in newer module versions pop up. This is not possible with in-tree.

btrfs (in-tree) had several data corruption bugs in the past. And you can not get around it because it is coming to you automatically with the kernel update. That is really a disaster. Even ext4 (in-tree) had silent data corruption bugs in the past (kernel 6.1.64/6.1.65). debian 12.3 release was delayed due to this.

bcachefs (in-tree) is so new that it is fair to assume that it will have its own bugs sooner or later.

You talk about zfs users as "out of tree fanatics"? I would rather call you an "in tree fanatic".

[mbod]

The changes that they've made to their data deduplication method sound like they're really polishing a turd. Constantly checking a table for duplicate blocks on every write sounds like a horrendous way to handle it. They should make a deduplication method that can work in the background or on a schedule and use block cloning rather than constantly maintaining some giant deduplication table.

Why dont you just open an issue on github and discuss this with the developers directly? https://github.com/openzfs/zfs
I am sure they will appreciate your ideas.

[ayumu]

Why dont you just open an issue on github and discuss this with the developers directly? https://github.com/openzfs/zfs
I am sure they will appreciate your ideas.

Please don't sent people like this to harass ZFS developers.

Particularly, when this is a license-related problem they can do nothing about.

Instead, try and get Linux to implement stable API interfaces for filesystems of any license to link against.