Re: current status of zfs block_cloning on CURRENT?

On Mon, Apr 24, 2023 at 9:49 PM Charlie Li <vishwin@freebsd.org> wrote:

> Charlie Li wrote:
> > Pete Wright wrote:
> >> i've seen a few threads about the block_cloning feature causing data
> >> corruption issues on CURRENT and have been keen to avoid enabling it
> >> until the dust settles.  i was under the impression that we either
> >> reverted or disabled block_cloning on CURRENT, but when i ran "zpool
> >> upgrade" on a pool today it reported block_cloning was enabled.  this
> >> is on a system i rebuilt yesterday.
> >>
> > The dust has settled.
> Barely...
> >> i was hoping to get some clarity on the effect of having this feature
> >> enabled, is this enough to trigger the data corruption bug or does
> >> something on the zfs filesystem itself have to be enabled to trigger
> >> this?
> >>
> > The initial problem with block_cloning [0][1] was fixed in commits
> > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and
> > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit
> > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption
> > problem [2][3] was fixed in commit
> > 63ee747febbf024be0aace61161241b53245449e. All were committed between
> > 15-17 April.
> >
> > [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103
> > [1] https://github.com/openzfs/zfs/pull/14739
> > [2] https://github.com/openzfs/zfs/issues/14753
> > [3] https://github.com/openzfs/zfs/pull/14761
> >
> Given mjg@'s thread reporting further crashes/panics, you may want to
> keep the sysctl disabled if you upgraded the pool already.
>

I thought the plan was to keep it disabled until after 14. And even then,
when it comes back in, it will be a new feature It should never be enabled.

Warner