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

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

>> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B