From nobody Mon Apr 17 23:36:55 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q0k3m2q3fz45Mrf for ; Mon, 17 Apr 2023 23:37:08 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q0k3m0Ht7z3FBH; Mon, 17 Apr 2023 23:37:08 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-24736992dd3so444991a91.1; Mon, 17 Apr 2023 16:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681774626; x=1684366626; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hX293cZyviiYnWe1PM/ddZahmUJCBNMyZQ1bg6qScaE=; b=Tp9+4x8Qum1y/IQqY2L+5qLAmDYQQCKzghAQndiCsdqVRVqRVtE4sGCR8XYN0M5d6g 8Ewe+qZEhyO2Xn/8LPKmXNEV6/RjwprxvcXLRj1pL8UMupIxZDtuXVSxKrsbWYt/pd+W PPBYtYrgRpeKcMEutVF+dbKSkngbaLpMyZC6spkHN966WqWDXNAtyyNRAKm2/RjvaWr+ 3Dl2OUqeb1TuZjCE/DxSMaFfsR4Aq55KivCt7d5TDyCDkODV29q7PoT2mzj1JWpeXvrG eZzaczCQjdG1uJ8ExvT+zkTsEB5PqmeagXWRUR2H73utAUiomRGjOlRAMnlOubg1pOFe BQEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681774626; x=1684366626; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hX293cZyviiYnWe1PM/ddZahmUJCBNMyZQ1bg6qScaE=; b=FQy9gMXcwOQugJmgUtBL9NU8Sn54GZKsnniQF8Z+gOXGtNhLJEo79LT4RGUWKtl68B eX6FzpfaAGOD4pW2DAWe0YoBij3BfcJGEfYGgMtZMIkajtjjIVQoAVWygL7uvMfWVaXC ybX8VBAt0iUSsvzfn9D11eRhR+x20l+/GG6IupX+ZrYyQ6fItpQmClJ9LenBL/oI7ZtH X4NrNw9XTDalxKgORXsgUSPyWNSD6fKFivwglKNiAiCrKrShaj4thUeO2DGsYhBX0zQu QL6v1WNIr3cuCkqkO91Y7hfdoyYTrpXif0G0rldBqHfomtWeKqnyT2pToVnuZtnT4FZq HE2g== X-Gm-Message-State: AAQBX9c2EBsOzCbbf5Zi3n+Fn9LpmEUOfGTeb9oLf3KoFzTCRsCnxMQ1 pk475CvgSgua3VQF2sSUfXiq7jr0wqmQwk8iUA== X-Google-Smtp-Source: AKy350aRoX2vxcL7cACS1bKARFX/SxNXxkCLbI31/1UsGhmMRZMuIyKQn524fLr4+91N2tOxxK1lSF/ZvqiMY37HOSk= X-Received: by 2002:a17:90b:ecb:b0:23f:3f9c:7878 with SMTP id gz11-20020a17090b0ecb00b0023f3f9c7878mr227712pjb.2.1681774626158; Mon, 17 Apr 2023 16:37:06 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <48e02888-c49f-ab2b-fc2d-ad6db6f0e10b@dawidek.net> <20230417232859.18262E2@slippy.cwsent.com> In-Reply-To: <20230417232859.18262E2@slippy.cwsent.com> From: Rick Macklem Date: Mon, 17 Apr 2023 16:36:55 -0700 Message-ID: Subject: Re: another crash and going forward with zfs To: Cy Schubert Cc: Pawel Jakub Dawidek , Mateusz Guzik , freebsd-current@freebsd.org, Glen Barber Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Q0k3m0Ht7z3FBH X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Apr 17, 2023 at 4:29=E2=80=AFPM Cy Schubert wrote: > > In message , Pawel Jaku= b > Dawi > dek writes: > > On 4/18/23 05:14, Mateusz Guzik wrote: > > > On 4/17/23, Pawel Jakub Dawidek 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 > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > >