OpenZFS 2.2.2 & OpenZFS 2.1.14 Released To Fix Data Corruption Issue

[User29]

it wasn't really a problem until Coreutils started doing things differently.

Ok, but if it was only triggered by the coreutils change, why were FBSD people panicking? BSDs don't use GNU stuff.

They should have just watched the show, munching popcorn.

[AlanTuring69]

It seems like it was a pretty clear problem in SEEK_HOLE/SEEK_DATA that could have easily been unit tested to see there was a problem.

If your argument is that nothing used this codepath, and it wasn't feasible to unit test, then it should have just been deleted - since if nothing uses it, there's no reason to keep untested code around.

That said, I get it - bugs happen. But your comment here is pretty obnoxious fanboy-sounding nonsense, so I had to reply.

I think it was a lot more complicated than that, otherwise they wouldn't have had to rely on some bespoke integration test to replicate it and prove it was fixed. It is nonetheless true that very solid + robust unit tests theoretically would have caught it, but it's also true that it's a kernel module which is not simple to unit test.

But because OpenZFS isn't named bcachefs or btrfs it's suddenly the most buggy filesystem ever to exist.

[Weasel]

The part that I thought you meant the C language

LMAO I just realized it, now I actually laughed for not noticing it.

Well, their new way of copying things did cause all of this data corruption to be made apparent in ZFS. While the ZFS code needed fixing, and there's no denying that, it wasn't really a problem until Coreutils started doing things differently.

I'm not blaming anyone and I mark this under shit happens as things advance.

Yeah which is exactly the same thing with the Linux kernel back then, I mean the way it did TRIM with queued TRIM (since buggy drives advertised support for it). They had to be blacklisted to stop corrupting data; TRIM on those drives is just regular slow TRIM now.

You can thank Windows for it for always lagging behind and "if it works on Windows it must be fine" devs, even hardware ones. -.-

[EphemeralEft]

Thanks! I'll write CBS. But they ceased production of new episodes. I'll need to convince Dr. Phil!

Something tells me Dr. Phil would love to have you.

[EphemeralEft]

But because OpenZFS isn't named bcachefs or btrfs it's suddenly the most buggy filesystem ever to exist.

BTRFS is absolutely treated like this. Considering how harsh this forum is to BTRFS, they're going easy on ZFS.

[NotMine999]

You could probably get some money and get a doctor Phil episode ?
"Ex zfs user escapes the ZFS cult"

Sounds like the basis for a new reality TV show.

[spicfoo]

But because OpenZFS isn't named bcachefs or btrfs it's suddenly the most buggy filesystem ever to exist.

On the contrary, all the Btrfs news were frequently inundated with folks trash talking it regularly despite it's usage as the default filesystem in so many distributions and mass production NAS systems. A lot of this was from very smug posts from ZFS users and this was always in very poor taste. Now the other shoe has dropped and they have to face the reality that ZFS also had multiple data corruption bugs fixed as part of this release and even now, rather than recognize it, some of them would prefer to furiously shift blame somewhere else instead (Phoronix is posting about this too much, coreutils is the problem etc). It's a good thing for everyone to realize that filesystems, especially ones with advanced features will more than likely have bugs that corrupt data and yes, this includes Bcachefs despite it's slogan. Even if filesystems are written perfectly, firmware in some of these storage disks will straight up make false claims and there is not a whole lot you can do about that. Redundancy can help but only if its entirely independent of the filesystem. If its just filesystem snapshots, you are likely just going to have multiple copies of the same corrupted file before you realize it.

[Developer12]

Unhandled events shouldn't be able to corrupt data though..

The bug doesn't occur when using older versions of corutils that rely on functions ZFS doesn't support.

[Developer12]

I appreciate the developers efforts to remedy this bug, and applaud their release of a hoped for fix.

But as I've commented on multiple threads concerning this issue now, no one on Earth has any way of knowing whether or not the bug has truly been fixed, because all inclusive specifications and documentation for ZFS, and official coverage and fuzz verification test suites, have never been developed.

Instead both ZFS and BTRFS simply have code compounded upon code, with developers adding and subtracting from it ad hominem, touting arbitrary scripts as "proof" it works. And if enough of the other developers agree it's added to an ever growing and fragmented test regime.

Look, I really like both of these file systems, and have great hope for bcachefs as well, but they all have to get organized or it will be a rare miracle if any of them succeed.

As I've said before they need to elect lead architects, finally and officially produce all encompassing specifications and documentation for their systems, and produce coverage and fuzz verification systems that are updated as their code changes.

As, at least for now, all we can do is cross our fingers and hope.

Have you even looked at ANY of the papers on ZFS' architecture? Here's the first one, to get you started:

https://www.cs.hmc.edu/~rhodes/cs134/readings/The%20Zettabyte%20File%20System.pdf

Another example: One of the lead architects of ZFS is Matthew Ahrens, as are people who signed off on the raidz expansion work last month.

Just because you're totally ignorant of all the things you mention doesn't mean they don't exist.

[Developer12]

BTRFS is absolutely treated like this. Considering how harsh this forum is to BTRFS, they're going easy on ZFS.

ZFS hasn't spawned new stories of people loosing data every week for the last 10+ years. BTRFS has. BTRFS is so bad that everyone who uses it has to continually preface their use of it with "in my personal experience I've never lost anything" because tons of people continue to every day. The only reason it's survived this long is a total lack of other in-tree alternatives. Hopefully bcachefs kills it off for good.