OpenZFS 2.2.2 & OpenZFS 2.1.14 Released To Fix Data Corruption Issue

[cj.wijtmans]

For all the nay sayers about "this should have been discovered..." or "where was all the testing..." The bug could NOT be triggered before coreutils changed the way it does file copies. The likelihood of anyone discovering it without someone knowing exactly what they were looking for was slim to none like any other bug that would be impossible to find when the code path to reach it doesn't exist.

nonsense. testing units dont only test if something goes well, there should be testing units for when something goes bad it does so gracefully.

[onlyLinuxLuvUBack]

Wow, you are brave. Or crazy.

You just insulted ZFS, the sacred cow of filesystems that can do everything and save your data from corruption.

You must be a Linux fanboy who loves Btrfs.

Well, you better watch out, because the ZFS mafia is after you. They will make you pay for your words and make you suffer.

They will spam you with ZFS lies, mock you with ZFS stats, bore you with ZFS stories. They will tell you that ZFS is perfect and flawless, the only solution for silent data corruption. They will bully you, threaten you, silence you.

But don't worry, you are not alone. There are others who agree with you, have seen the truth and escaped the ZFS cult. There are others who have found a better, newer, faster way. Those have switched to a different filesystem that has all the cool features of Btrfs and ZFS, but none of the drawbacks. One filesystem that is faster, simpler, and more stable than Btrfs and ZFS. One that is still evolving.

But I can't tell you the name of this filesystem, because it is a forbidden word here. If I say it out loud, the ZFS mafia will hear me, find me and kill me. They hate, fear and envy this filesystem and know that it's superior. It's the future and the ultimate threat to their monopoly. They know that it is the only filesystem that can rival, surpass and replace ZFS.

So I will only give you a hint. It's made by a man who has created a masterpiece that can do what ZFS or other filesystem couldn't. This man has given us hope, freedom, progress and choice.

But be careful, don't say it too loud. Please don't say it at all. The ZFS mafia is watching, listening and waiting. They will stop at nothing to destroy this filesystem, its creator and its users. They will stop at nothing to preserve their power, their prestige, their pride. They will stop at nothing to defend their filesystem, their religion, their god.

ZFS fails again, again and again. But there's hope.

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

[phoenix_rizzen]

So, is this a Linux-only bug? Or FreeBSD is also affected by it?

This is a ZFS bug that goes back to ZFS releases on Illumos, affecting all systems that used Illumos-based ZFS (including FreeBSD) through to OpenZFS 2.2 (including FreeBSD and Linux). IOW, pretty much any system that used ZFS in the past 10-ish years.

However, just because the bug existed for this long doesn't mean it's affected systems for this long. Read through the FreeBSD errata notice to see just how hard it is to hit this bug (not impossible, just very miniscule time window for very specific things to occur). It's not until hole-detecting processes became part of everyday utilities (like cp) that the chances increased to the point where the bug became visible.

[Siuoq]

Given the complexity of ZFS and the complexity of filesystems in general, especially with features like sparse files, compression, asynchronity and so on... There are probably a few more silent killer bugs hidden. Not only in ZFS, but in all filesystems.

XFS or ext4 are probably good tho.

What if a filesystem were as simple as possible, and all the funny stuff were handled by a layer above it?

[Weasel]

C is for Coreutils and Z for ZFS

Uhm, yes?

What part of my post did not assume that, again?

You blame Coreutils ("C") for "causing issues" when it's literally ZFS's fault. Literally no different than the Linux kernel in my analogy with queued TRIM. After all, Windows' kernel didn't support it at the time, so clearly it was Linux kernel's fault for "causing issues" eh?

[skeevy420]

Uhm, yes?

What part of my post did not assume that, again?

The part that I thought you meant the C language

You blame Coreutils ("C") for "causing issues" when it's literally ZFS's fault. Literally no different than the Linux kernel in my analogy with queued TRIM. After all, Windows' kernel didn't support it at the time, so clearly it was Linux kernel's fault for "causing issues" eh?

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.

[timofonic]

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

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

[timofonic]

XFS or ext4 are probably good tho.

What if a filesystem were as simple as possible, and all the funny stuff were handled by a layer above it?

Do you mean something like Stratis on steroids? That layer would be full of bugs, plus a lot slower than a better integrated implementarion. Rust would reduce it, but just the mem leak part and such.

[muncrief]

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.

[smitty3268]

For all the nay sayers about "this should have been discovered..." or "where was all the testing..." The bug could NOT be triggered before coreutils changed the way it does file copies. The likelihood of anyone discovering it without someone knowing exactly what they were looking for was slim to none like any other bug that would be impossible to find when the code path to reach it doesn't exist.

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.