[Bug 275308] EN tracking issue for potential ZFS data corruption

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275308

--- Comment #15 from Alexander Leidinger <netchild@FreeBSD.org> ---
(In reply to Dave Cottlehuber from comment #14)

> 12.x existing zpools:

It is not known if there is an impact or not. There are now reports that
OpenZFS 0.6.x could be affected and people want to test the initial Solaris ZFS
release for this bug.

> Open questions:

It doesn't matter if cp uses lseek() or not. There exist applications out there
which make use if it, and as such the likelyhood of an issue is not 0. As it
also relies on parallel read/write operations and the right timing, the
likelyhood may be very small
(https://github.com/openzfs/zfs/issues/15526#issuecomment-1826182928 states
0.00027% of real world corruption for a particular use case, but no idea how
likely this use case is for others... or what the use case was).

What we know is that poudriere runs on 15-current where block cloning is
enabled can trigger the issue in a way that multiple people have stumbled over
it. For all the previous years we are not aware of any obvious use case which
may have triggered the problem in a way that someone would have attributed it
to ZFS. So yes, we need to fix it. Yes it is a good idea to use the sysctl to
even decrease the likelyhood. But no, we should not have sleepness nights. If
you don't use ECC RAM I would guess the likelyhood of having bad data due to a
RAM issue is higher.

-- 
You are receiving this mail because:
You are the assignee for the bug.