I'm reading through the bug report and the investigation in the comments. Is there something here that makes this bug extremely obvious to you that nobody else is comprehending?

A FreeBSD developer wrote this code.

and then there were deep concerns about the stability of same, so vfs.zfs.bclone_enabled = 0 was left in-place

https://github.com/freebsd/freebsd-src/commit/068913e4ba3dd9...

So far nobody has proven that this bug exists on FreeBSD, though. :)

The bugs are in cross platform code beneath the VFS. They exist on FreeBSD too.

Because FreeBSD is behind Linux in copying with reflinks. They couldn't even reproduce the issue if they wanted to.

This code was implemented for FreeBSD before it was implemented for Linux. I do not think it has made it to a FreeBSD release yet though.

It’s in FreeBSD 14. But they disabled block cloning by default.

No it wasn't: https://github.com/openzfs/zfs/issues/405

This hit Linux first, which is why Linux experienced the issue. FreeBSD does not currently have reflink cp.

Looks like a deeper bug has been exposed due to the way bclone works? They're finding issues now on ZFS versions predating bclone

Edit: yep, it's an older bug. Set zfs_dmu_offset_next_sync=0 to save your data

https://github.com/openzfs/zfs/issues/15526#issuecomment-182...

Not sure what's your point. The comment I linked to just confirmed that the bug (whichever it might be) has reproduced on FreeBSD.

Just following up for the readers of the thread

Nope, somebody managed to reproduce this issue even with zfs_dmu_offset_next_sync=0

https://github.com/openzfs/zfs/issues/15526#issuecomment-182...

Apply this patch, it appears to be the real fix.

https://github.com/openzfs/zfs/pull/15571/files?diff=split&w...

>How the heck did this ever make it through?

Because it was introduced by a FreeBSD developer, and FreeBSD's fs and cp are a generation behind Linux's so they weren't even able to hit this.

>I don't think this ever would have happened pre-OpenZFS, and undermines the stable reputation of ZFS.

Of course it happened pre-OpenZFS: https://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss...

From the people that brought you Slowlaris.

>OpenZFS needs to do better and look to FreeBSD developers, not Linux developers, as role models.

This was introduced by a FreeBSD developer and was caught by a Linux one. You need to rethink your role models.

>Because it was introduced by a FreeBSD developer, and FreeBSD's fs and cp are a generation behind Linux's

This is often regarded as a good thing in the BSD world. In all fairness, this bug just enforces that notion.

And Solaris (at least on amd64) wasn't slow. It was demanding, and not really suited for desktop. And it was picky with hardware.

Totally agree on the rest of your comment, though.

>This is often regarded as a good thing in the BSD world. In all fairness, this bug just enforces that notion.

Same in Linux, which is why you'd choose a distro that's less bleeding edge.

>And Solaris (at least on amd64) wasn't slow.

No, it was slow. There's a reason why everyone in HPC/HFT/etc. moved off Solaris to Linux in the 2000s. Linux was regularly beating Slowlaris in practically every category at the end.

>Because it was introduced by a FreeBSD developer, and FreeBSD's fs and cp are a generation behind Linux's so they weren't even able to hit this.

Honestly, this feature could have used more testing on both platforms.

Also, FreeBSD's VFS in theoretically able to support reflinks across datasets while Linux's VFS disallows that. It is not really behind.

>FreeBSD's VFS in theoretically able to support reflinks across datasets while Linux's VFS disallows that.

I don't believe so, you're still not able to hardlink across file systems in BSD.

>It is not really behind.

It is behind: https://github.com/openzfs/zfs/issues/405

It seems like a meme that GPL software developers are more ego driven than BSD/MIT software developers, and so bike shedding and new features take precedence over correctness/simplicity/beauty. I was a decade long Gentoo user who was frustrated by crashy software, switched back to pirated windows (I would never be caught dead paying for windows), only to find out the same trash developer habits carried over in my absence and now windows sucks just as much plus IT SPIES ON YOU!!! I'm now on Qubes OS hoping Xen is well enough built to assuage my anxieties.

The Linux developers involved use the CDDL. While some of them have patches in Linus’ tree, most of them are described as Linux developers because they develop and use the code on Linux. They have little to do with mainline Linux, partly because certain the mainline Linux developers will actively go out of their way to antagonize them if they even try to contribute to mainline. Certain others will simply ignore their emails. I will not say names, but I have had that happen to me in the past.

That said, I suspect you did not read the replies, since the code in question was written by a FreeBSD developer. Bugs in new code have been introduced by developers on both platforms. Unfortunately, the bugs in this feature were not caught before they reached a stable release. :/

> bike shedding and new features take precedence over correctness/simplicity/beauty.

I just learned the recent FreeBSD 14 release doesn't have 802.11n WiFi support. Is that considered bike shedding?

You don't have to enable all these fancy new features in your zpools even if you update your build of zfs if you don't want to.

I have multiple zpools and none of them have been upgraded to enable any of these new features in the past couple years.

That alone probably protected a number of users from hitting this.