tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Hi :)

On Fri, Mar 18, 2022 at 09:21:26AM -0400, Mouse wrote:
> 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.

Sounds workable

> 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?

> 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. 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 (!!). I think this is the default behaviour anyway on NFS mounts
that can take quite some time to succeed.

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.

Is this what you envisioned?

With regards,
Reinoud

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index