Re: current status of zfs block_cloning on CURRENT?

On Tue, Apr 25, 2023 at 12:35:29AM -0700, Mark Millard wrote:
> Warner Losh <imp_at_bsdimp.com> wrote on
> Date: Tue, 25 Apr 2023 04:30:26 UTC :
> 
> > 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.
> 
> 
> https://lists.freebsd.org/archives/freebsd-current/2023-April/003514.html
> 
> had Pawel Jakub Dawidek reporting adding a sysctl vfs.zfs.bclone_enabled
> to allow the feature to be actually in use in 14, with a default that
> would not have it in use. (Any cases of previously enable but not "in
> use" here is wording simplification as I understand: special handling
> if active from a previous pool upgrade and later activity so that
> it cleans itself up, or something like that.)


ah ok thanks for that insight.  on my system where i did upgrade the
pool i have this sysctl:
$ sysctl vfs.zfs.bclone_enabled
vfs.zfs.bclone_enabled: 0

which seems to jive with the statement above.

thanks!
-p

-- 
Pete Wright
pete@nomadlogic.org