From nobody Thu May 19 17:36:25 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 4664D1AE8DFC for ; Thu, 19 May 2022 17:36:28 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.6]) (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 4L3xqG6QPRz3RJs for ; Thu, 19 May 2022 17:36:26 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.3] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 595842DB7E for ; Thu, 19 May 2022 17:36:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 595842DB7E Message-ID: Date: Thu, 19 May 2022 13:36:25 -0400 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 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: zfs support in makefs Content-Language: en-US To: freebsd-hackers@freebsd.org References: <20220518230427.GI15201@spindle.one-eyed-alien.net> From: Allan Jude In-Reply-To: <20220518230427.GI15201@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L3xqG6QPRz3RJs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.51.186.6 is neither permitted nor denied by domain of allanjude@freebsd.org) smtp.mailfrom=allanjude@freebsd.org X-Spamd-Result: default: False [-2.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[allanjude]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.50)[-0.504]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:209.51.160.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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. > > 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=[:=[:=[:...]]]". 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 >> "/". 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. > > 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 In normal `zpool create` they use -o for pool properties, and -O for dataset properties for the root dataset. I wonder if we might also want -o poolprop=value and -O zroot/var:mountpoint=/var:canmount=off just to avoid the conceptual collision of those 2 different items. One other possible issue: dataset properties can have a : in them, for user-defined properties. Do we maybe want to use a , to separate them instead? Although values can contain ,'s (the sharenfs property often does), so that probably doesn't work either. -- Allan Jude