From nobody Fri May 20 12:37:01 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 09CF91B3D486 for ; Fri, 20 May 2022 12:37:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4L4R7X6Jf6z4sdk; Fri, 20 May 2022 12:37:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-111-80.area1b.commufa.jp [123.1.111.80]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 24KCb2DT073432; Fri, 20 May 2022 21:37:02 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 20 May 2022 21:37:01 +0900 From: Tomoaki AOKI To: Brooks Davis Cc: Allan Jude , Mark Johnston , freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-Id: <20220520213701.73a826e711b58a1799006825@dec.sakura.ne.jp> In-Reply-To: <20220519182532.GJ15201@spindle.one-eyed-alien.net> References: <20220518230427.GI15201@spindle.one-eyed-alien.net> <20220519182532.GJ15201@spindle.one-eyed-alien.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L4R7X6Jf6z4sdk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-0.37 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.35)[-0.355]; NEURAL_HAM_SHORT(-0.41)[-0.412]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.111.80:received] X-ThisMailContainsUnwantedMimeParts: N On Thu, 19 May 2022 18:25:32 +0000 Brooks Davis wrote: > 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. > > > > > > 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. > > Sadly -O is taken in makefs. > > > 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. > > One solution would be to allow the same fs=foo: 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 Just an idea, what about moving partitioning (create pool) functionality to sbin/gpart, keeping relatively common functionality for datasets on /usr/sbin/makefs as primary proposal, and create, for example, /usr/sbin/makefs_zfs for complicated, ZFS-only functionalities. It would look like gpart / mount / mount_* on other supported fs. And keeps common makefs simper. IIRC, some fs-specific mount_* have extended functionality, that `mount -t (fstype)` does not support. -- Tomoaki AOKI