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

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Do we have any valid need to have non-critical local filesystems?

I thought so.

> Not for Paul's reason ("critical" here has nothing to do with
> importance or requirement for operation - just mount ordering)

I thought "critical" in the critical_filesystems_{local,remote} sense
meant "contains something necessary enough that it has to be available
ASAP and the system shouldn't even try to finish coming up if it's
missing", typically something needed by the rest of the boot process,
such as /usr/bin and /usr/sbin on a system where they aren't part of /.

> Something like that is still needed, though even that isn't really
> good enough, as filesystem mounting can be nested in all kinds of
> bizarre ways,

True.  But, as I see it, there are really two ordering dependencies
here, and they are only semi-orthogonal.

There is "this FS must be mounted for the system to come up at all"
(which as I mentioned above is what I thought "critical" in this
context meant) and there is "fs A must be mounted before we can even
try to mount fs B", which is what you want for things like
"/usr/src/bin/sh is mounted under /usr/src".

Arguably mount -a (and relatives like -A) should sort filesystems so
that if mount-point A is a path prefix of mount-point B (path prefix,
not string prefix, since /usr/src is not necessary for /usr/src2), then
the mount of A must be attempted before the mount of B.  (If mounting A
fails, then mounting B will presumably fail too because its mount-on
point won't exist - and, if it does exist, it is probably a sysadmin
trying to provide a fallback so that, eg, you can work on sh even if
the rest of /usr/src isn't accessible).  The mount source I have does
not include any such sorting code, though it _is_ moderately old.

So it seems to me that the right thing is to have some way (a script,
an option to mount, wwhatever) that says "mount this filesystem, but
first mount any path prefixes of it".  This would be used for each
critical (in the above sense) filesystem, early in boot.  Then, later
in boot, something like mount -a (with the above ordering hacks, if
they're not already present) would mount all other filesystems.

It's not quite that simple, of course, because of network-remote
filesystems and networking.  It probably should be something like

critlocal
	Mount critical local filesystems.  Either use an option to
	automatically mount filesystems necessary for them, or require
	the admin to (eg) configure /foo as also critical if /foo/bar
	is critical.
networking
	Start networking.
critremote
	Mount critical remote filesystems.  Again, include any
	path-prefix filesystems by one of the above two methods.
noncritical
	Mount all remaining filesystems, in some path-prefix order.

with the ordering among those four steps enforced by some means such as
rcorder keywords.

Filesystem mount-point nesting I would address by teaching mount -a and
friends to sort the mount list in path-prefix order, for the
"noncritical" step above, and by either doing something related for the
earlier critical mounts or just requiring the admin to list the prefix
filesystems as critical - and then doing the looping in a predictable
(and documented!) order so the admin can make the prefix filesystem get
mounted first.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B