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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 14 Mar 2022 16:16:24 -0400
    From:        Brad Spencer <brad%anduin.eldar.org@localhost>
    Message-ID:  <xonlexcl27b.fsf%anduin.eldar.org@localhost>

  | I can't really think of any time when a local filesystem was optional.

That happens all the time, particularly if you consider that filesystems
are first class objects that deserve to be used, and not just an obstacle
to deal with limited capacity on drives, and that the world would be better
if there was simply space to use.

One of my systems has (along with more important ffilesystems) this:

/dev/dk28       4990798    2362274    2378985  49% /usr/src
/dev/dk36        922022     407674     468247  46% /usr/src/pkgsrc
/dev/dk33       1284114     802011     417897  65% /usr/src/freebsd
/dev/dk42      20719388    6629836   13053584  33% /usr/obj
/dev/wd1l     314440762   86038642  212680082  28% /local/shifter
/dev/dk50       7878669    4063668    3421067  54% /local/netbsd
/dev/raid2e     4095126    1150582    2739788  29% /local/jade
/dev/raid2m     4220942    2000430    2009466  49% /local/jade/old/mail
/dev/raid1h     5111401    1545176    3055085  33% /local/jade/old/src
/dev/raid1i      984574     331282     554835  37% /local/jade/old/src/pkgsrc
/dev/raid4e    40579756   34972076    2767098  92% /cvsroot
/dev/dk40      83864440   79024424     646800  99% /local/distfiles
/dev/dk45      20955246   19312790     594694  97% /local/distfiles-retired
/dev/raid4p    41526936   37538840    1081216  97% /local/packages
/dev/dk62     125811992  108372552   11148848  90% /local/snap
/dev/dk41      62905944   59144072     616576  98% /local/prev-snap
/dev/raid4n    41571864   39513464    -851624 102% /local/old-snap
/dev/dk44      41926812   20398944   19431528  51% /local/iso
/dev/dk38       8259989    5807356    2039634  74% /release/current
/dev/dk51       8185357    4270059    3506031  54% /release/testing
/dev/dk70       6126438    3105478    2775903  52% /release/9
/dev/dk46       8135317    2667263    5061289  34% /release/8
/dev/dk47       8259989    4852605    2994385  61% /release/7
/dev/dk39       8259989    3665798    4181192  46% /release/6
/dev/dk59       4099710    1588187    2306538  40% /local/testsrc

absolutely none of which is needed for its fundamental purpose of
being the Dom0 that supports munnari.oz.au (and other stuff).   Any
of that being gone when the system comes up would be no more than
a nuisance.

Much of that hasn't been touched in ages, the /local/jade stuff
are filesystems that came from the system that this one replaced
about a decade ago.   They were used for a month or so after that...

To those I could add /home which also isn't really needed for the
system to work (but would be a bigger nuisance if it were missing).

There are a whole bunch more local filesystems that aren't currently
mounted, stuff like /release/9/i386 /release/9/amd64 which become
the DESTDIR for builds, and then get unmounted, and booted as root
of their own DomU (so they're usually unmounted here).

So, add me to the list of people who'd like a "mount if possible"
switch, with nothing more than a boot warning if some of them cannot
be found at all, or have unfixable fsck issues.

I'd actually prefer even more - for most of those, if the filesystem
isn't clean, and it isn't just a matter of "replay the log" to deal
with it, I'd prefer that the filesys simply be skipped until the
system is up multi-user, and then the necessary fsck fix be attempted
while the system is carrying on with its real work, and if successful
the mount be performed later (so some of that junk might be missing for
a while after a boot following an unclean shutdown, but most of it
will come back later).

But not all that way, things like /usr/obj I'd prefer to simply
allow to start unmounted if it has issues - then I'd simply newfs
the thing and start again (or have that automated even).  That
would allow me to mount it async which currently is just a recipe
for "boot will fail and need attention in single user mode", so isn't
safe to use, though it results in much faster file creation/deletion,
which for something like /usr/obj is ideal (if the system had enough
RAM I'd just use a tmpfs or mfs, unfortunately, it doesn't).

Certainly all this can be accomplished by ad-hoc scripts, but it
seems like something that many people actually would use, and we'd
benefit if this was done in a standard way.

kre