Date: Mon, 24 Apr 2023 22:30:26 -0600 From: Warner Losh <imp@bsdimp.com> To: Charlie Li <vishwin@freebsd.org> Cc: Pete Wright <pete@nomadlogic.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: current status of zfs block_cloning on CURRENT? Message-ID: <CANCZdfozip=mGFQCK8ks3_A0p0OuQSpx1-r-Dtx6Wpix-huUjQ@mail.gmail.com> In-Reply-To: <9c55271b-e2cf-85b7-cc99-00ddcb76f98e@freebsd.org> References: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> <9c55271b-e2cf-85b7-cc99-00ddcb76f98e@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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. Warner [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 24, 2023 at 9:49 PM Charlie Li <<a href="mailto:vishwin@freebsd.org">vishwin@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Charlie Li wrote:<br> > Pete Wright wrote:<br> >> i've seen a few threads about the block_cloning feature causing data <br> >> corruption issues on CURRENT and have been keen to avoid enabling it <br> >> until the dust settles. i was under the impression that we either <br> >> reverted or disabled block_cloning on CURRENT, but when i ran "zpool <br> >> upgrade" on a pool today it reported block_cloning was enabled. this <br> >> is on a system i rebuilt yesterday.<br> >><br> > The dust has settled.<br> Barely...<br> >> i was hoping to get some clarity on the effect of having this feature <br> >> enabled, is this enough to trigger the data corruption bug or does <br> >> something on the zfs filesystem itself have to be enabled to trigger <br> >> this?<br> >><br> > The initial problem with block_cloning [0][1] was fixed in commits <br> > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and <br> > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit <br> > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption <br> > problem [2][3] was fixed in commit <br> > 63ee747febbf024be0aace61161241b53245449e. All were committed between <br> > 15-17 April.<br> > <br> > [0] <a href="https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103" rel="noreferrer" target="_blank">https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103</a><br>; > [1] <a href="https://github.com/openzfs/zfs/pull/14739" rel="noreferrer" target="_blank">https://github.com/openzfs/zfs/pull/14739</a><br>; > [2] <a href="https://github.com/openzfs/zfs/issues/14753" rel="noreferrer" target="_blank">https://github.com/openzfs/zfs/issues/14753</a><br>; > [3] <a href="https://github.com/openzfs/zfs/pull/14761" rel="noreferrer" target="_blank">https://github.com/openzfs/zfs/pull/14761</a><br>; > <br> Given mjg@'s thread reporting further crashes/panics, you may want to <br> keep the sysctl disabled if you upgraded the pool already.<br></blockquote><div><br></div><div>I thought the plan was to keep it disabled until after 14. And even then,</div><div>when it comes back in, it will be a new feature It should never be enabled.</div><div><br></div><div>Warner <br></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfozip=mGFQCK8ks3_A0p0OuQSpx1-r-Dtx6Wpix-huUjQ>