Date: Tue, 25 Apr 2023 00:35:29 -0700 From: Mark Millard <marklmi@yahoo.com> To: Warner Losh <imp@bsdimp.com>, Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: current status of zfs block_cloning on CURRENT? Message-ID: <6F5B60BD-C5D2-4145-813D-263C52E05A02@yahoo.com> References: <6F5B60BD-C5D2-4145-813D-263C52E05A02.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=E2=80=AFPM Charlie Li = <vishwin@freebsd.org> wrote: >=20 > > 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. > > >=20 > 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.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6F5B60BD-C5D2-4145-813D-263C52E05A02>