>> 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.
> That'll need specifying say the need for '/' and '/usr' and other
> more common mount points but what about non standard mountpoints?
That would be handled by the admin per-system. For example, on a few
of my systems full networking startup requires /local/bin; it would (in
this scenario) be my responsibility to ensure that networking startup
is marked as requiring any mountpoints needed for /local/bin to work.
(Which may be none if, for example, all of /local is on /).
>> 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.)
> I don't think its that hard to implement; Its basically splitting the
> mount system call in two sections.
Right.
> First a kind of 'mount_attempt' call that creates the (locked) VNODE
> as normal before now issuing the VFS_MOUNT call. All access to it
> will block as required then. Note that this node should auto unlock
> and fail-all and be-recycled on the linked process exit or on the
> actual mount system-call (!!).
Well, we don't want to fail blocked I/O if the fsck succeeds and the
final mount happens. Aside from that, this sounds like what I meant.
There could be issues around getwd() in directories whose parent chains
involve siblings of the mount point.
> In the meantime the mount(8) program can then fork and execute its
> fsck variant on it and depending on its return value either exit with
> failure or do the actual mount call.
Approximately, yes.
> Is this what you envisioned?
Yes, I think so. You have gone into much more detail than I had, but
it sounds very much like what I had in mind. The biggest issues I
would expect to have are the ones surrounding dealing with / (and any
other mountpoints needed for this - I'd be inclined to require that the
binaries involved be on /). I suspect / may have to continue to be
handled more or less the way it is now: fsck before anything else,
remount or reboot depending on the result, then carry on with startup.
I've added this to my to-do list. Dunno when - or even whether - I'll
get around to it, but at least it's there.
/~\ 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
