>> Though it seems like a good discussion in that some real progress
>> was made, in that the lack of a "noerror" or "allowfail" or whatever
>> flag [...]
> The major issue is that it requires the results of the fsck to be
> available to the mount stage, which isn't so easy to do when both are
> just using -a and all rc knows from fsck is "something failed" or
> "all ok".
Right. Solving that is one of the harder problems involved, I would
say. Simply adding flags to fsck and mount is easy.
But I would say that, if the infrastructure makes a useful thing
difficult, it is at least worth considering that perhaps the right
thing is to change the infrastructure rather than abandoning doing the
thing. In this case, that applies to the rc machinery.
I'd have to think about whether I think it's best to do that with state
bits in the filesystems in question, state bits in a filesystem object
elsewhere, state bits in a non-filesystem object elsewhere (a
persistent shared memory segment?) or some kind of "part of one, part
of another" (an AF_LOCAL socket?), state kept by the scripts, or what.
Complicating this is filesystems (eg msdos, ntfs, ext2) which are
externally defined and which it's thus difficult to add state bits to.
Another option might be for all optional systems to be fscked and
mounted in the background, without even delaying rc for them, never
mind erroring if they fail. This makes it possible to handle the error
reporting via things like mail that aren't available during early
startup.
Getting even more radical (and intrusive to the status quo), I would
suggest having _all_ fsck and mount runs happening in the background,
with other rc stuff delaying until the filesystem(s) needed is/are
mounted. (Figuring out how to handle / would be one of the interesting
bits.) Then "optional" ("noerror", "allowfail", whatever) filesystem
handling happens automatically - they aren't explicitly marked; they
are just the ones that nothing blocks waiting for.
To go even further, have the mounts partially happen, with accesses to
the mountpoint blocking, until fsck finishes and the mount is released;
that way the "wait for things it needs" part is automatic. (Failures
by fsck or mount would then lead to the nascent mountpoint being torn
down, with I/O blocked waiting for it returning errors.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
