Date: Mon, 14 Mar 2022 16:16:24 -0400
From: Brad Spencer <b...@anduin.eldar.org>
Message-ID: <xonlexcl27b....@anduin.eldar.org>
| 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
