Date: Tue, 25 Apr 2023 16:10:42 -0700 From: Pete Wright <pete@nomadlogic.org> To: Mark Millard <marklmi@yahoo.com> Cc: Warner Losh <imp@bsdimp.com>, Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: current status of zfs block_cloning on CURRENT? Message-ID: <our47m7oqhzypufmbi6gyandcoiqmuzoua5nrwk2itn2oappeu@uws24zhahxz6> In-Reply-To: <6F5B60BD-C5D2-4145-813D-263C52E05A02@yahoo.com> References: <6F5B60BD-C5D2-4145-813D-263C52E05A02.ref@yahoo.com> <6F5B60BD-C5D2-4145-813D-263C52E05A02@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?our47m7oqhzypufmbi6gyandcoiqmuzoua5nrwk2itn2oappeu>