Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Simon Burge <simonb%NetBSD.org@localhost> writes:

> [ Moving this from source-changes-d to tech-userlevel and combining
> a couple of messages with one rambling reply. ]
>

[snip]

> I'm using ZFS as my root filesystem, with the EFI boot loader reading
> the kernel from the ZFS root filesystem.  This is based on the the
> FreeBSD libsa ZFS code. https://github.com/snarkophilus/src/tree/zfsboot
> is this work, and I'm planning on merging into main NetBSD sources soon.

Nice to hear of this.  Maybe it will be possible one day to have a Xen
DOMU PVH that uses MBR do something simular or even maybe a DOMU PV with
a ZFS root filesystem.


>> Ya, I suspect that the notion of precedence needs to be developed
>> somehow and not abuse the notion of critical too much.  That is,
>> filesystem mounting by type needs to happen in a particular order.  The
>> default would have to choose something, either making not ZFS happen
>> first followed by normal and usual ZFS pools, or the other way around.
>
> Another idea that came up in off-list discussion with Taylor is in the
> same vein as this - the whole notion of "critical".  So changing from
>
>         mountcritlocal
>         mountcritremote
>         mountall
>
> to
>
>         mountlocal
>         mountcritremote
>         mountremote
>
> or even just a simpler
>
>         mountlocal
>         mountremote
>
> Do we have any valid need to have non-critical local filesystems?

That is a very good question... I think not, actually..  At least in the
uses I have messed with, I can't really think of any time when a local
filesystem was optional.

[snip]

>> I suspect that someone loses out as no default can handle every way that
>> ZFS may be used when other filesystem types are present.  For example,
>> in the cases I have, a FFS is the root filesystem along with other FFS
>> file systems.  Under these are ZFS normal pools, so the order I would
>> prefer in this case is mount FFS first and then import the pools, as the
>> places that the pools would mount under would not exist the other way
>> around.  However, I very much understand that the other way around could
>> exist where ZFS normal pools are imported before anything else.
>
> I think if you have complex ordering requirements with a mix of ZFS
> and other filesystem types, then you are probably better off using ZFS
> legacy mounts?

That would not be a preference of mine as legacy ZFS mounts do not deal
well with some of the ZFS feature that I use.  They are fine for just a
single mounted entity, but can't really deal with fileset inheritance.

This is what I do on my build systems.  They are DOMU PVs, so the root
filesystem pretty much has to be FFS (I would love to be proven wrong
here, BTW, and shown a functional way to do a root ZFS filesystem for a
DOMU PV).  My set up looks a lot like this:

/usr/sources -> a ZFS pool (or fileset) is homed here
/usr/sources/CURRENT -> this is a ZFS fileset off of the sources pool (or fileset)
/usr/sources/NetBSD_9 -> another ZFS fileset off of the sources pool (or fileset)

These filesets are simply created by 'zfs create ....' and populated and
updated with cvs in the normal and usual way one does that.

When I want to build a new version of -current, I do this [meta typing
of commands here, nothing promised to work as presented, just for
illustration purposes]:

zfs snapshot sources/CURRENT@<todaysdate>
zfs clone sources/CURRENT@<todaysdate> sources/CURRENT_<todaysdate>

This has the effect of creating a new fileset in /usr/sources/CURRENT_<todaysdate>

I can also use a 'zfs send ... | zfs receive ...' pipeline to get a copy
of the fileset / snapshot if I didn't want to have the ZFS clone
dependency involved.

I do the same thing for the build artifacts with /usr/artifacts.  One or
more pools may be involved in this set up, although right now I am using
a tank pool that holds both the sources and artifacts.  None of this
involves messing with /etc/fstab or legacy mounts.

The point is that by need /usr/sources has to be realized in the system
after / and /usr are available and right now those can't be a ZFS pool
themselves (well, /usr COULD be, but I can't really see how / could).
This, at least in my opinion, is not a complicated nor unusual use
case.  However, if it were possible for / and /usr to be a ZFS fileset
or pool then the requirements change a bit.


-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org