Re: FreeBSD 13.2R and OpenZFS bug #15933

From: Daniel Tameling <tamelingdaniel_at_gmail.com>
Date: Fri, 01 Mar 2024 06:22:17 UTC
On Wed, Feb 28, 2024 at 06:08:14PM -0800, David Christensen wrote:
> 
> OpenZFS bugs #15526 and #15933 appear to be integration bugs that involve
> the (Linux) kernel, GNU coreutils, and ZFS.  The test case involves setting
> up a Portage system for Go on Gentoo Linux (?) and examining files manually
> for zeroed holes where non-zero values should be.  I do not know if the test
> case can be run on FreeBSD, if there is a test case for these bugs on
> FreeBSD, or if the bugs do not apply to FreeBSD because the kernel is not
> Linux (?).

Bug 15526 worked as follows: If you have a recently modified file and
read it, you get the correct data. But if you ask ZFS if it contains
holes there is a tiny window when gives you the wrong answer.
Coreutils changed the defaults of cp for the latest major release,
making it ask for holes. Go enters the picture as when it was
compiling stuff it was copying a lot of recently modified files and
some of the copies ended up with holes they shouldn't have had. The
probability for this was very low but it was reproducible. The nasty
thing about this was that the checksums were correct as they were
computed for the new files.

So several things needed to come together: 1) recently modified files,
2) copy them almost simultaneously while 3) looking for holes. Even
then it was relatively rare to hit the bug, which is why it remained
undetected for so long.

Here is a write-up of the person that fixed the bug containing all the
gory details:
https://despairlabs.com/blog/posts/2023-12-25-openzfs-data-corruption-bug/


> > > Does this new OpenZFS bug [#15933] affect FreeBSD 13.2R?
> > 
> > [#15933] mentions using block cloning which 13.2R does not include or
> > support on the base system. Though a pool may have that enabled, I
> > thought it was still disabled with a sysctl (that I hope never goes
> > away even when 100% bug free; its important to be able to rewrite
> > data on disk when desired). I am not sure if the bug is only produced
> > when block cloning is enabled or if block cloning just brings out a
> > different bug. Until the bug is properly 'debugged' or further
> > diagnosed, it would be hard to say what systems reproduce the issue
> > and under what conditions.
> 
> 
> So, is my data safe on up-to-date FreeBSD 13.2R ZFS with native encryption
> disabled?
> 

It's safer than on FreeBSD 12 but nobody will give you any guarantees.

--
Best regards
Daniel