Re: zfs support in makefs

On Wed, May 18, 2022 at 11:04:27PM +0000, 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.
> 
> Very cool!
> 
> > === Interface ===
> > 
> > Creating a pool with a single dataset is easy:
> > 
> > $ makefs -t zfs -s 10g -o poolname=test ./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=test -o fs=test:setuid=off:atime=on ./zfs.img /path/to/input
> > 
> > It's also possible to create additional datasets:
> > 
> > $ makefs -t zfs -s 10g -o poolname=test -o fs=test/ds1:mountpoint=/test/dir1 ./zfs.img /path/to/input
> > 
> > The parameter syntax is
> > "-o fs=<dataset name>[:<prop1>=<val1>[:<prop2>=<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 overrides
> > its default mountpoint, its children inherit that mountpoint.
> > 
> > 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.
> > 
> > The -o rootpath parameter defines this root mount point.  By default it'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=/.
> > 
> > Putting it all together, one can build a image using the standard layout
> > with an invocation like this:
> > 
> > makefs -t zfs -o poolname=zroot -s 20g -o rootpath=/ -o bootfs=zroot/ROOT/default \
> >     -o fs=zroot:canmount=off:mountpoint=none \
> >     -o fs=zroot/ROOT:mountpoint=none \
> >     -o fs=zroot/ROOT/default:mountpoint=/ \
> >     -o fs=zroot/tmp:mountpoint=/tmp:exec=on:setuid=off \
> >     -o fs=zroot/usr:mountpoint=/usr:canmount=off \
> >     -o fs=zroot/usr/home \
> >     -o fs=zroot/usr/ports:setuid=off \
> >     -o fs=zroot/usr/src \
> >     -o fs=zroot/usr/obj \
> >     -o fs=zroot/var:mountpoint=/var:canmount=off \
> >     -o fs=zroot/var/audit:setuid=off:exec=off \
> >     -o fs=zroot/var/crash:setuid=off:exec=off \
> >     -o fs=zroot/var/log:setuid=off:exec=off \
> >     -o fs=zroot/var/mail:atime=on \
> >     -o fs=zroot/var/tmp:setuid=off \
> >     ${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/image_zfs.sh#L79
> > 
> > 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=*: prefix, but making users type
> "pool:" for other options doesn't seem to make sense so this is probably
> the best solution.

Yeah, this was exactly my reasoning for the current syntax.  It might be
worth revisiting if we end up adding many more options, but I would like
to try and keep makefs as simple as possible.

> 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.

I thought about this too.  We have several definitions of the standard
FreeBSD ZFS dataset layout scattered around, in bsdinstall, poudriere,
and probably elsewhere.  release(7) would get yet another instance; see
D23334 and D34426.

So, it'd be nice to have a single definition (and perhaps some
alternative layouts) defined somewhere central, ideally in a format that
can also be consumed by OpenZFS tools.  OpenZFS might already have
something like this, I don't know.