From nobody Thu May 19 16:32: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 810541B47F24 for ; Thu, 19 May 2022 16:32:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3wPT43v3z3D0m; Thu, 19 May 2022 16:32:29 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x830.google.com with SMTP id x7so1965201qta.6; Thu, 19 May 2022 09:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Kuqogi4m9X8C3HLnaNxO+vYrErV/8K7afchiDSdiQ44=; b=cnI78/u45SI++CSIxoHNNOkcz0MdqDkRCGSFoFAMNfHLEel6YiM7h2Aiq+zwXeX5lC 1AAfLBOAawKjY2hH5D/LyPeQUhid4ifndQvMdcXBBY3AIi/xqYUpZlEVNxRrnxPLrRmC /NeKui5SPBB7GbiS9DzJUGBu9ol95Vc1+P5yq0uY7z2xFd0iSCEWAYbMJMRuyicIEDcJ R4O3B+gNJi9UGeqEJggcBy97CEuWih85VeWpKvQMPW94ZU2OJHzh/CNhPPXUZoBathZ7 fSagKfvMPXMV4Tru0J1Pq0TuDLc6BC+oab7Y+capUC9vVbOpUGd9rmeNmjQDS2X0cLiY hOeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=Kuqogi4m9X8C3HLnaNxO+vYrErV/8K7afchiDSdiQ44=; b=h0ANQQpiZsQZEhJFwjc7/y8zVqBUDiK3KZv6V88U4253iwvGuBceiNDsaVTjKJgA3C RkWZYmRcmne2IHhUncobw8r+Un3Rg8mqpQHhTy+wpAOPRSLKUaCTwZd/nwf5ME4PKdNl YQU2SNVKcRI8T89GYaJ2YY8qESq3AZ5y7VL5Za9oZO8gtzWF9CO0D+JNjjW135WTRcUJ fK+a3LllqGslW7JYFKohKdetHg9dZb2/PQZlaiL30cbmDLt5G9jRGJCYq/GkbSv+0Xmo 6+u/Cc0xqs3RPMnH82VrlSOccxO2g5BpmGUzL0qcHLArpE0xE2Uk06kVVZVqIhPwfZzc tCJw== X-Gm-Message-State: AOAM532FXPDJWa/AcBHD1IvNqhTn7g02GRKKnGiFOhiRmGBjrwpIoJbU o7suWF3pKTthRD+NRXSefor0Z+0pHFo= X-Google-Smtp-Source: ABdhPJz3xkDaPTknBj/WqLRSgejkIdcuhQ69fx78HJpopH+XxRM/haFbj6WYf5B/a9s9pvoCPiL0cg== X-Received: by 2002:a05:622a:1a15:b0:2f7:3b31:7d86 with SMTP id f21-20020a05622a1a1500b002f73b317d86mr4550937qtb.1.1652977948405; Thu, 19 May 2022 09:32:28 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id d14-20020ac847ce000000b002f90a33c78csm1478567qtr.67.2022.05.19.09.32.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 May 2022 09:32:27 -0700 (PDT) Date: Thu, 19 May 2022 12:32:25 -0400 From: Mark Johnston To: Brooks Davis Cc: freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-ID: References: <20220518230427.GI15201@spindle.one-eyed-alien.net> 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-Disposition: inline In-Reply-To: <20220518230427.GI15201@spindle.one-eyed-alien.net> X-Rspamd-Queue-Id: 4L3wPT43v3z3D0m X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="cnI78/u4"; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.52 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.96)[-0.962]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.88)[-0.876]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; NEURAL_HAM_SHORT(-0.99)[-0.985]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N 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=[:=[:=[:...]]]". 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. 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.