Re: current status of zfs block_cloning on CURRENT?

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.)

Presuming no ability to have the feature actually in use ( so no
ability to set vfs.zfs.bclone_enabled ), there also is then the
question of reverting the block_cloning related code in the
source vs. just blocking its (non-cleanup) activity.

Also, there are folks that ended up with block_cloning enabled and a
question is what is intended for 14.0-RELEASE for them: Require them
to create a new pool that is not upgraded but has the content
transfered? Allow them to use the pools in 14.0-RELELASE?

I think all 3 of those are showing up in the exchanges that are
happening. Sometimes it can be unclear for one or more of those what
the status intended is --but they are not fully independent issues.

(My wording is likely a simplification in various ways.)

===
Mark Millard
marklmi at yahoo.com