Date: Thu, 19 May 2022 18:25:32 +0000 From: Brooks Davis <brooks@freebsd.org> To: Allan Jude <allanjude@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-ID: <20220519182532.GJ15201@spindle.one-eyed-alien.net> In-Reply-To: <d907e65a-2a1a-7482-d533-f4c18841d8ca@freebsd.org> References: <YoVC9VgV1nTptjzx@nuc> <20220518230427.GI15201@spindle.one-eyed-alien.net> <d907e65a-2a1a-7482-d533-f4c18841d8ca@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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<dataset name>[:<prop1>=3D<val1>[:<prop2>=3D<val2>[:...]]]". =
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
> >> "/<poolname>". 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220519182532.GJ15201>