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 <vish...@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
