Date: Mon, 17 Apr 2023 16:36:55 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, Mateusz Guzik <mjguzik@gmail.com>, freebsd-current@freebsd.org, Glen Barber <gjb@freebsd.org> Subject: Re: another crash and going forward with zfs Message-ID: <CAM5tNy7GoSuWZMKdmUeSWG241FbdEQXxSj6aW7qirk%2Bfk8AZKg@mail.gmail.com> In-Reply-To: <20230417232859.18262E2@slippy.cwsent.com> References: <CAGudoHH8vurcn4ydavi-xkGHYA6DVfOQF1mEEXkwPvGUTjKZNA@mail.gmail.com> <48e02888-c49f-ab2b-fc2d-ad6db6f0e10b@dawidek.net> <CAGudoHEWFNcdrFcK30wLSN8%2B56%2BK4CfqwUDsvb1%2BZwS1Gt4NXg@mail.gmail.com> <b57b06bd-7e73-ae2d-2fba-bd226883ff34@dawidek.net> <20230417232859.18262E2@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 17, 2023 at 4:29=E2=80=AFPM Cy Schubert <Cy.Schubert@cschubert.= com> wrote: > > In message <b57b06bd-7e73-ae2d-2fba-bd226883ff34@dawidek.net>, Pawel Jaku= b > Dawi > dek writes: > > On 4/18/23 05:14, Mateusz Guzik wrote: > > > On 4/17/23, Pawel Jakub Dawidek <pjd@freebsd.org> wrote: > > >> Correct me if I'm wrong, but from my understanding there were zero > > >> problems with block cloning when it wasn't in use or now disabled. > > >> > > >> The reason I've introduced vfs.zfs.bclone_enabled sysctl, was to exa= ctly > > >> avoid mess like this and give us more time to sort all the problems = out > > >> while making it easy for people to try it. > > >> > > >> If there is no plan to revert the whole import, I don't see what val= ue > > >> removing just block cloning will bring if it is now disabled by defa= ult > > >> and didn't cause any problems when disabled. > > >> > > > > > > The feature definitely was not properly stress tested and what not an= d > > > trying to do it keeps running into panics. Given the complexity of th= e > > > feature I would expect there are many bug lurking, some of which > > > possibly related to the on disk format. Not having to deal with any o= f > > > this is can be arranged as described above and is imo the most > > > sensible route given the timeline for 14.0 > > > > Block cloning doesn't create, remove or modify any on-disk data until i= t > > is in use. > > > > Again, if we are not going to revert the whole merge, I see no point in > > reverting block cloning as until it is enabled, its code is not > > executed. This allow people who upgraded the pools to do nothing specia= l > > and it will allow people to test it easily. > > In this case zpool upgrade and zpool status should return no feature > upgrades are available instead of enticing users to zpool upgrade. The > userland zpool command should test for this sysctl and print nothing > regarding block_cloning. I can see a scenario when a user zpool upgrades > their pools, notices the sysctl and does the unthinkable. Not only would > this fill the mailing lists with angry chatter but it would spawn a numbe= r > of PRs plus give us a lot of bad press for data loss. > > Should we keep the new ZFS in 14, we should: > > 1. Make sure that zpool(8) does not mention or offer block_cloning in any > way if the sysctl is disabled. > > 2. Print a cautionary note in release notes advising people not to enable > this experimental sysctl. Maybe even have it print "(experimental)" to wa= rn > users that it will hurt. > > 3. Update the man pages to caution that block_cloning is experimental and > unstable. I would suggest going a step further and making the sysctl RO for FreeBSD14= . (This could be changed for FreeBSD14.n if/when block_cloning is believed to be debugged.) I would apply all 3 of the above to "main", since some that install "main" will not know how "bleeding edge" this is unless the above is done. (Yes, I know "main" is "bleeding edge", but some still expect a stable test system will result from installing it.) Thanks go to all that tracked this problem down, rick > > It's not enough to have a sysctl without hiding block_cloning completely > from view. Only expose it in zpool(8) when the sysctl is enabled. Let's > avoid people mistakenly enabling it. > > > -- > Cheers, > Cy Schubert <Cy.Schubert@cschubert.com> > FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org > NTP: <cy@nwtime.org> Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy7GoSuWZMKdmUeSWG241FbdEQXxSj6aW7qirk%2Bfk8AZKg>