From nobody Mon Sep 18 21:37:20 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 4RqJ6Z3x1Kz4tnDQ; Mon, 18 Sep 2023 21:37:26 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RqJ6Y6RZqz4XPL; Mon, 18 Sep 2023 21:37:25 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 38ILbKTW077663; Tue, 19 Sep 2023 06:37:20 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Tue, 19 Sep 2023 06:37:20 +0900 From: Tomoaki AOKI To: Alexander Motin Cc: Martin Matuska , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: vfs.zfs.bclone_enabled (was: FreeBSD 14.0-BETA2 Now Available) Message-Id: <20230919063720.e1e0b449863f2860ace51376@dec.sakura.ne.jp> In-Reply-To: References: <20230916002831.GU52318@FreeBSD.org> <02c53c2e-127b-33b4-e13d-f6f6589dd5fe@gmail.com> <7a6692de-f096-637d-fe48-d5fb93e54f8b@FreeBSD.org> <8e4e4000-4680-0550-6772-32a6a3101761@FreeBSD.org> <20230918202204.28e21a011a0a98e3fcda9f3a@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4RqJ6Y6RZqz4XPL At least, if I read the code correctly, "com.fudosecurity:block_cloning", should be added to array *features_for_read[] of stand/libsa/zfs/zfsimpl.c. There are check codes like below, so without it, boot codes would reject to boot from any pool having block_cloning feature enabled. Am I missing something? > for (i = 0; features_for_read[i] != NULL; i++) { > if (memcmp(nvp_name->nv_data, features_for_read[i], nvp_name->nv_size) == 0) { > found = 1; > break; > } > } > > if (!found) { > printf("ZFS: unsupported feature: %.*s\n", > nvp_name->nv_size, nvp_name->nv_data); > rc = EIO; > } Regards. On Mon, 18 Sep 2023 09:26:56 -0400 Alexander Motin wrote: > block_cloning feature is marked as READONLY_COMPAT. It should not > require any special handling from the boot code. > > On 18.09.2023 07:22, Tomoaki AOKI wrote: > > Really OK? > > > > I cannot find block_cloning in array *features_for_read[] of > > stand/libsa/zfs/zfsimpl.c, which possibly mean boot codes (including > > loader) cannot boot from Root-on-ZFS pool having block_cloning active. > > > > Not sure adding '"com.fudosecurity:block_cloning",' here is sufficient > > or not. Possibly more works are needed. > > > > IMHO, all default-enabled features should be safe for booting. > > Implement features with disalded, impement boot codes to support them, > > then finally enable them by default should be the only valid route. > > > > > > [1] https://cgit.freebsd.org/src/tree/stand/libsa/zfs/zfsimpl.c > > > > > > On Mon, 18 Sep 2023 07:31:46 +0200 > > Martin Matuska wrote: > > > >> I vote for enabling block cloning on main :-) > >> > >> mm > >> > >> On 16. 9. 2023 19:14, Alexander Motin wrote: > >>> On 16.09.2023 01:25, Graham Perrin wrote: > >>>> On 16/09/2023 01:28, Glen Barber wrote: > >>>>> o A fix for the ZFS block_cloning feature has been implemented. > >>>> > >>>> Thanks > >>>> > >>>> I see > >>>> , > >>>> with > >>>> > >>>> in stable/14. > >>>> > >>>> As vfs.zfs.bclone_enabled is still 0 (at least, with 15.0-CURRENT > >>>> n265350-72d97e1dd9cc): should we assume that additional fixes, not > >>>> necessarily in time for 14.0-RELEASE, will be required before > >>>> vfs.zfs.bclone_enabled can default to 1? > >>> > >>> I am not aware of any block cloning issues now.  All this thread about > >>> bclone_enabled actually started after I asked why it is still > >>> disabled. Thanks to Mark Millard for spotting this issue I could fix, > >>> but now we are back at the point of re-enabling it again.  Since the > >>> tunable does not even exist anywhere outside of FreeBSD base tree, I'd > >>> propose to give this code another try here too.  I see no point to > >>> have it disabled at least in main unless somebody needs time to run > >>> some specific tests first. > > > > -- > Alexander Motin -- Tomoaki AOKI