Date: Tue, 25 Apr 2023 07:56:33 -0700 From: Pete Wright <pete@nomadlogic.org> To: Warner Losh <imp@bsdimp.com>, Charlie Li <vishwin@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: current status of zfs block_cloning on CURRENT? Message-ID: <6052c5c7-cc32-c1ea-6943-aaebd0b9b02f@nomadlogic.org> In-Reply-To: <CANCZdfozip=mGFQCK8ks3_A0p0OuQSpx1-r-Dtx6Wpix-huUjQ@mail.gmail.com> References: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> <9c55271b-e2cf-85b7-cc99-00ddcb76f98e@freebsd.org> <CANCZdfozip=mGFQCK8ks3_A0p0OuQSpx1-r-Dtx6Wpix-huUjQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------MkHvJs0pwSFTDOLkNx7PlcZm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/24/23 21:30, Warner Losh wrote: > > > 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. > that was my reading of things too - thanks for the tip on disabling the sysctl knob Charlie, I'll do that. if this is really intended to be live i'd like to suggest we update zpool-features(7) at the least so others aren't caught by surprise. i'd propose a PR myself, but I'm not %100 clear on what its intent is. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA --------------MkHvJs0pwSFTDOLkNx7PlcZm Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <br> <br> <div class="moz-cite-prefix">On 4/24/23 21:30, Warner Losh wrote:<br> </div> <blockquote type="cite" cite="mid:CANCZdfozip=mGFQCK8ks3_A0p0OuQSpx1-r-Dtx6Wpix-huUjQ@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openzfs/zfs/pull/14739</a><br>; > [2] <a href="https://github.com/openzfs/zfs/issues/14753" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openzfs/zfs/issues/14753</a><br>; > [3] <a href="https://github.com/openzfs/zfs/pull/14761" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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> </div> </blockquote> <br> that was my reading of things too - thanks for the tip on disabling the sysctl knob Charlie, I'll do that.<br> <br> if this is really intended to be live i'd like to suggest we update zpool-features(7) at the least so others aren't caught by surprise. i'd propose a PR myself, but I'm not %100 clear on what its intent is.<br> <br> -pete<br> <br> <pre class="moz-signature" cols="72">-- Pete Wright <a class="moz-txt-link-abbreviated" href="mailto:pete@nomadlogic.org">pete@nomadlogic.org</a> @nomadlogicLA</pre> </body> </html> --------------MkHvJs0pwSFTDOLkNx7PlcZm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6052c5c7-cc32-c1ea-6943-aaebd0b9b02f>