Ed Maste, the Director of Project Development for The FreeBSD Foundation, sent the following email in the freebsd-stable mailing list, regarding a new ZFS issue. It appears that it affects earlier versions of OpenZFS and it is not related to block cloning.

Dear FreeBSD community,

We want to bring your attention to a potential data corruption issue
affecting multiple versions of OpenZFS. It was initially reported
against OpenZFS 2.2.0 but also affects earlier and later versions.

This issue can be reproduced with targeted effort but it has not been
observed frequently in real-world scenarios. This issue is not related
to block cloning, although it is possible that enabling block cloning
increases the probability of encountering the issue.

It is unclear if the issue is reproducible on the version of ZFS in
FreeBSD 12.4.

A short term workaround is available for FreeBSD 14.0 and 13.2 by
setting the vfs.zfs.dmu_offset_next_sync sysctl to 0:

echo vfs.zfs.dmu_offset_next_sync=0 >> /etc/sysctl.conf

sysctl vfs.zfs.dmu_offset_next_sync=0

The workaround may result in inaccurate reporting of file holes in
sparse files, reintroducing OpenZFS issue 6958[1]. See the ZFS(4) man
page for more information on this setting.

The workaround does not deterministically prevent the issue but does
drastically reduce the likelihood of encountering it.

For more information, see OpenZFS issue 15526[2] and OpenZFS pull
request 15571[3]. FreeBSD bug report PR 275308[4] is open to track the
FreeBSD erratum update which will bring in the fix, after it is
committed to OpenZFS. Please check the FreeBSD PR regularly if you are
looking for details on the timeline of the FreeBSD erratum update.

We want to assure the FreeBSD community that we are actively monitoring the situation. Thank you for your understanding and continued support.

<https://lists.freebsd.org/archives/freebsd-stable/2023-November/001726.html>