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
--000000000000cbfd0105fa2195c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 24, 2023 at 9:49=E2=80=AFPM Charlie Li <vishwin@freebsd.org> wr= ote: > 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 --000000000000cbfd0105fa2195c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 24, 2023 at 9:49=E2=80=AF= PM Charlie Li <<a href=3D"mailto:vishwin@freebsd.org">vishwin@freebsd.or= g</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"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 causin= g data <br> >> corruption issues on CURRENT and have been keen to avoid enabling = it <br> >> until the dust settles.=C2=A0 i was under the impression that we e= ither <br> >> reverted or disabled block_cloning on CURRENT, but when i ran &quo= t;zpool <br> >> upgrade" on a pool today it reported block_cloning was enable= d.=C2=A0 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 feat= ure <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 trigg= er <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 commi= t <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=3D"https://github.com/openzfs/zfs/pull/13392#issuecomment-= 1504239103" rel=3D"noreferrer" target=3D"_blank">https://github.com/openzfs= /zfs/pull/13392#issuecomment-1504239103</a><br> > [1] <a href=3D"https://github.com/openzfs/zfs/pull/14739" rel=3D"noref= errer" target=3D"_blank">https://github.com/openzfs/zfs/pull/14739</a><br>; > [2] <a href=3D"https://github.com/openzfs/zfs/issues/14753" rel=3D"nor= eferrer" target=3D"_blank">https://github.com/openzfs/zfs/issues/14753</a><= br> > [3] <a href=3D"https://github.com/openzfs/zfs/pull/14761" rel=3D"noref= errer" target=3D"_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 featur= e It should never be enabled.</div><div><br></div><div>Warner <br></div></d= iv></div> --000000000000cbfd0105fa2195c9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfozip=mGFQCK8ks3_A0p0OuQSpx1-r-Dtx6Wpix-huUjQ>