From nobody Wed May 18 23:04:27 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 C03A91AE390C for ; Wed, 18 May 2022 23:04: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 4L3T8K4c3Sz4m31; Wed, 18 May 2022 23:04:33 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 940BD3C0199; Wed, 18 May 2022 23:04:27 +0000 (UTC) Date: Wed, 18 May 2022 23:04:27 +0000 From: Brooks Davis To: Mark Johnston Cc: freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-ID: <20220518230427.GI15201@spindle.one-eyed-alien.net> References: 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="Encpt1P6Mxii2VuT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4L3T8K4c3Sz4m31 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 [-1.10 / 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)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.18)[0.175]; NEURAL_HAM_SHORT(-0.99)[-0.993]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.62)[0.615]; 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 --Encpt1P6Mxii2VuT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 18, 2022 at 03:03:17PM -0400, Mark Johnston wrote: > Hi, >=20 > 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. Very cool! > =3D=3D=3D Interface =3D=3D=3D >=20 > Creating a pool with a single dataset is easy: >=20 > $ makefs -t zfs -s 10g -o poolname=3Dtest ./zfs.img /path/to/input >=20 > Upon importing such a pool, you'll get a dataset named "test" mounted at > /test containing everything under /path/to/input. >=20 > It's possible to set properties on the root dataset: >=20 > $ makefs -t zfs -s 10g -o poolname=3Dtest -o fs=3Dtest:setuid=3Doff:atime= =3Don ./zfs.img /path/to/input >=20 > It's also possible to create additional datasets: >=20 > $ makefs -t zfs -s 10g -o poolname=3Dtest -o fs=3Dtest/ds1:mountpoint=3D/= test/dir1 ./zfs.img /path/to/input >=20 > The parameter syntax is > "-o fs=3D[:=3D[:=3D[:...]]]". On= ly a > few properties are supported, at least for now. >=20 > 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 overrides > its default mountpoint, its children inherit that mountpoint. >=20 > makefs builds the output filesystem using a single input directory tree. > 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. >=20 > The -o rootpath parameter defines this root mount point. By default it'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/. >=20 > Putting it all together, one can build a image using the standard layout > with an invocation like this: >=20 > makefs -t zfs -o poolname=3Dzroot -s 20g -o rootpath=3D/ -o bootfs=3Dzroo= t/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 >=20 > 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/imag= e_zfs.sh#L79 >=20 > What do folks think of this interface? Is there anything missing, or > anything that doesn't make sense? 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. 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. -- Brooks --Encpt1P6Mxii2VuT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJihXt6AAoJEKzQXbSebgfAN3cH+QE2L7vE4W7FBudP6U7KtYKd 34EqGrZO41PyzuBWYzNnUgNSZ5DaQKaOsX7e/gejoe4y8MJvAwkq3UzhKZJJzx5f sKCWPKdYsL547hlH73keb6DivOt0KUl5JQ8yacNtQC/VSptwSxGx3QZ42R0Ni68y fWTrbc3HopgSykRrOPIfRgC28peFU9Yx2/lPL1tmr0lqfdANIEbb4ec8uNXYQ4Al QlQmeb9FTLS08b5wkDmdnkCUbiaDS3ndfFsjXg5N2UqDiLyzj98tBXaY7hGDF3M/ IZQpa9fC1RxVGJrf2Z14ie6YmT6xRUbjFjTsSOSMqjTn8PCbT8g5tjqw0FbWlIw= =orTB -----END PGP SIGNATURE----- --Encpt1P6Mxii2VuT--