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

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

--- Comment #14 from Dave Cottlehuber <dch@freebsd.org> ---
for the inevitable EN (errata notice) could we also clarify some related info?

This is my understanding as of this morning, have I gotten this right.

Generally:

- testing of a new feature uncovered a rare and long-standing bug in OpenZFS
- the block cloning feature increased the likelihood of encountering this bug
- but it is still very very rare, and relies on a combination of high i/o, cpu,
and unusual write/read patterns
- this error will not be picked up by scrub or other zfs consistency checks
- setting vfs.zfs.dmu_offset_next_sync=0 should mitigate the likelihood of
encountering this error going forwards until a patch is made available

14.0-RELEASE new zpools:

- block cloning feature is disabled by default via vfs.zfs.bclone_enabled=0
- a newly created zpool in will have the zpool feature@block_cloning enabled
- but will not actively use that because of the sysctl
- thus actual impact is unlikely

13.x existing zpools:

- you may have encountered this bug but there is currently no definitive way
  to scan a zpool to check for the occurrence

12.x existing zpools:

- should not be impacted

Open Questions:

- I don't understand whether FreeBSD uses a similar sparse-by-default
functionality (like linux coreutils 9.2/9.3) that alters the user risk here

I'm happy to help craft/review an EN if needed.

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