From nobody Thu May 19 18:25:32 2022 X-Original-To: freebsd-hackers@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 0FC2F1B376D9 for ; Thu, 19 May 2022 18:25:34 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3yvx17fpz3vXJ; Thu, 19 May 2022 18:25:33 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 6C1503C0199; Thu, 19 May 2022 18:25:32 +0000 (UTC) Date: Thu, 19 May 2022 18:25:32 +0000 From: Brooks Davis To: Allan Jude Cc: freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-ID: <20220519182532.GJ15201@spindle.one-eyed-alien.net> References: <20220518230427.GI15201@spindle.one-eyed-alien.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ed/6oDxOLijJh8b0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4L3yvx17fpz3vXJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-2.79 / 15.00]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.78)[-0.781]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-0.11)[-0.112]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-ThisMailContainsUnwantedMimeParts: N --ed/6oDxOLijJh8b0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 19, 2022 at 01:36:25PM -0400, Allan Jude wrote: > On 5/18/2022 7:04 PM, Brooks Davis wrote: > > On Wed, May 18, 2022 at 03:03:17PM -0400, Mark Johnston wrote: > >> Hi, > >> > >> For the past little while I've been working on ZFS support in makefs(8= ). > >> At this point I'm able to create a bootable FreeBSD VM image, using the > >> standard FreeBSD ZFS layout, and run through the regression test suite > >> in bhyve. I've also been able to create and boot an EC2 AMI. > >=20 > > Very cool! > >=20 > >> =3D=3D=3D Interface =3D=3D=3D > >> > >> Creating a pool with a single dataset is easy: > >> > >> $ makefs -t zfs -s 10g -o poolname=3Dtest ./zfs.img /path/to/input > >> > >> Upon importing such a pool, you'll get a dataset named "test" mounted = at > >> /test containing everything under /path/to/input. > >> > >> It's possible to set properties on the root dataset: > >> > >> $ makefs -t zfs -s 10g -o poolname=3Dtest -o fs=3Dtest:setuid=3Doff:at= ime=3Don ./zfs.img /path/to/input > >> > >> It's also possible to create additional datasets: > >> > >> $ makefs -t zfs -s 10g -o poolname=3Dtest -o fs=3Dtest/ds1:mountpoint= =3D/test/dir1 ./zfs.img /path/to/input > >> > >> The parameter syntax is > >> "-o fs=3D[:=3D[:=3D[:...]]]". = Only a > >> few properties are supported, at least for now. > >> > >> Dataset mountpoints behave the same as they would if created with the > >> standard ZFS tools. So by default the root dataset's mountpoint is > >> /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrid= es > >> its default mountpoint, its children inherit that mountpoint. > >> > >> makefs builds the output filesystem using a single input directory tre= e. > >> Thus, makefs -t zfs requires that at least one of the dataset's > >> mountpoints map to /path/to/input; that is, there is a "root" mount > >> point. > >> > >> The -o rootpath parameter defines this root mount point. By default i= t's > >> "/". All datasets in the pool must have their mountpoints > >> under this path, and one dataset's mountpoint must be equal to this > >> path. To build bootable images, one sets -o rootpath=3D/. > >> > >> Putting it all together, one can build a image using the standard layo= ut > >> with an invocation like this: > >> > >> makefs -t zfs -o poolname=3Dzroot -s 20g -o rootpath=3D/ -o bootfs=3Dz= root/ROOT/default \ > >> -o fs=3Dzroot:canmount=3Doff:mountpoint=3Dnone \ > >> -o fs=3Dzroot/ROOT:mountpoint=3Dnone \ > >> -o fs=3Dzroot/ROOT/default:mountpoint=3D/ \ > >> -o fs=3Dzroot/tmp:mountpoint=3D/tmp:exec=3Don:setuid=3Doff \ > >> -o fs=3Dzroot/usr:mountpoint=3D/usr:canmount=3Doff \ > >> -o fs=3Dzroot/usr/home \ > >> -o fs=3Dzroot/usr/ports:setuid=3Doff \ > >> -o fs=3Dzroot/usr/src \ > >> -o fs=3Dzroot/usr/obj \ > >> -o fs=3Dzroot/var:mountpoint=3D/var:canmount=3Doff \ > >> -o fs=3Dzroot/var/audit:setuid=3Doff:exec=3Doff \ > >> -o fs=3Dzroot/var/crash:setuid=3Doff:exec=3Doff \ > >> -o fs=3Dzroot/var/log:setuid=3Doff:exec=3Doff \ > >> -o fs=3Dzroot/var/mail:atime=3Don \ > >> -o fs=3Dzroot/var/tmp:setuid=3Doff \ > >> ${HOME}/tmp/zfs.img ${HOME}/tmp/world > >> > >> I'll admit this is somewhat clunky, but it doesn't seem worse than what > >> we have to do otherwise, see poudriere-image for example: > >> https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/i= mage_zfs.sh#L79 > >> > >> What do folks think of this interface? Is there anything missing, or > >> anything that doesn't make sense? > >=20 > > I find it slightly confusing that -o options have a default namespace of > > pool options unless they have an fs=3D*: prefix, but making users type > > "pool:" for other options doesn't seem to make sense so this is probably > > the best solution. > >=20 > > The density of data in the filesystem specification does suggest that > > someone might want to create a UCL config file format eventually, but > > what's here already seems entirely workable. > >=20 > > -- Brooks >=20 > In normal `zpool create` they use -o for pool properties, and -O for=20 > dataset properties for the root dataset. I wonder if we might also want= =20 > -o poolprop=3Dvalue and -O zroot/var:mountpoint=3D/var:canmount=3Doff >=20 > just to avoid the conceptual collision of those 2 different items. Sadly -O is taken in makefs. > One other possible issue: dataset properties can have a : in them, for=20 > user-defined properties. Do we maybe want to use a , to separate them=20 > instead? Although values can contain ,'s (the sharenfs property often=20 > does), so that probably doesn't work either. One solution would be to allow the same fs=3Dfoo: to be specified multiple times (I've not checked if the current code allows this) to add options instead of having a separator. That does make the command line even more clunky though. -- Brooks --ed/6oDxOLijJh8b0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJihoubAAoJEKzQXbSebgfAZKUIAIth64pe7VjTgkOPXoakQ9VL D+oZRbZe78wL9hLiqSYLdGWMyZUO4lcw6QkQXdGKDit+ohT2JxqRTh8eUfjggbCx B7uuc2zh99LxNgGc1XLlXctM6/2bBGzHiciBdmQ9aDk6jnXc+EMn8Eux5F/kVaRo qZif3neBVmWtnTpmy8R08OdVLW5ZFMj0JVD9jNd3sAtp1Kf9BK7RSymbbYj/ZCxl zHOvWULi2tSo/pqV+9cJlFgWxm7cvjYvmcAmSUmel1ZtduGNU+krAy4751jbGPk0 h7k/fwi0pJrGL1A3352x7eMTrVqggyotPAubzkHtFTdGPZcM+qR4U/TdPWc2gzk= =n4bd -----END PGP SIGNATURE----- --ed/6oDxOLijJh8b0--