From nobody Thu Nov 10 00:32:06 2022 X-Original-To: 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 4N72pq2D7Wz4dmvK for ; Thu, 10 Nov 2022 00:32:19 +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 4N72pp4qNkz3hhL; Thu, 10 Nov 2022 00:32:18 +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 2AA0W6UB075709; Thu, 10 Nov 2022 09:32:07 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 10 Nov 2022 09:32:06 +0900 From: Tomoaki AOKI To: "Patrick M. Hausen" Cc: Alexander Leidinger , Warner Losh , Mark Millard , tsoome@freebsd.org, Li-Wen Hsu , current@freebsd.org Subject: Re: changes to the zfs boot (was: Re: git: 72a1cb05cd23 - main - rc(8): Add a zpoolupgrade rc.d script) Message-Id: <20221110093206.661bbe915fd2e37338df51be@dec.sakura.ne.jp> In-Reply-To: References: <202211070339.2A73dJlO027991@gitrepo.freebsd.org> <20221108105053.Horde.eqgFiBJe2ngGAj6BkXcv5-Z@webmail.leidinger.net> <20221109134610.Horde.JB7ibQTWprHbmIUfhg7JY7f@webmail.leidinger.net> <460205F9-5D59-4033-813B-C34E01BFD6C4@hausen.com> <20221109220540.Horde.6GRfN8bbUC4AsLcvjhWbUgm@webmail.leidinger.net> <65689194-1F56-4429-9A52-794A8354D995@hausen.com> <20221109222600.Horde.yo1Ry8tPu9udiPqUgtdDHNG@webmail.leidinger.net> <40D4F908-CE30-4AAF-89FA-E6849027FB17@hausen.com> <20221109225904.Horde.a8xggy6etutDDjHEEeWpdpb@webmail.leidinger.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4N72pp4qNkz3hhL 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-ThisMailContainsUnwantedMimeParts: N On Wed, 9 Nov 2022 23:04:17 +0100 "Patrick M. Hausen" wrote: > Hi, > > > Am 09.11.2022 um 22:59 schrieb Alexander Leidinger : > > Quoting "Patrick M. Hausen" (from Wed, 9 Nov 2022 22:47:28 +0100): > >> > >> I apologize, should have included that in the last mail. > >> This is a current FreeBSD 13.1-p2 hosting system we run. > >> [ List of features from an active root pool ] > >> Boots quite fine ;-) > > > > There are several in the list which are not in the list in zfsipl.c. So that list is not the full truth... > > Or whatever is missing is not critical to booting. The boot loader does not need > read/write access to the zpool. It only needs to be able to locate and read the kernel. > > Kind regards, > Patrick loader needs to read /boot/loader.conf, related scripts and kmods under /boot/ from boot pool, too. Not just kernel. Maybe, `zpool upgrade` would need some overhaul, with small change to stand/libsa/zfs/zfsimpl.c. *Move features_for_read[] alone to new, dedicated header that can be included from both stand/libsa/zfs/zfsimpl.c and any others (including zpool). *Let zpool to check whether the pool is bootable or not, and if bootable, only enable features included in the matrix, otherwise, enable all supported features on FreeBSD. I don't think ALL OS'es that have OpenZFS inported can always boot with all features enabled. So changes to zpool would be able to OS independent except the header defining features supported by its loader. There can be other matrixes for implemented (after boot) and default-to-be-enabled features. The OS-dependent matrixes would ease ZFS developers to determine which features are implemented / defaulted / bootable on specific OS. (Already there?) -- Tomoaki AOKI