Re: Fixing swap1_stop

[Robert Elz <kre%munnari.OZ.AU@localhost>]

After thinking about this (that is, the original problem here,
not the mount changes, which are useful for other reasons - the
reason I did the implementation I showed is that I have a very
similar need in some of my scripts, where I have just been "knowing"
that I never have weird chars, like spaces, in any of the mount point
names, up to now.)

Anyway, after thinking about it for a bit, I am not convinced that
any fix in the rc scripts is the best way to solve the underlying
problem - and at best it means a bunch of messy config that users
would need to maintain.

Might it not be better instead to fix it in the kernel, make it
so that if umount -f encounters a device node from the filesystem being
unmounted, it simply marks the vnode so it is known its home filesystem
has vanished (pointer to mount-point = NULL most probably -- so no more
attempts to update the times, which is all that the underlying filesys
is ever used for after a device is opened) and otherwise leave it alone?

(A regular umount, without -f, would return EBUSY as normal.)

That way the device keeps on working, until it is closed, when the vnode
can just be trashed, and in the meantime, the filesystem it came from can
be cleanly unmounted (or as cleanly as -f ever permits.)  In the general case
we really want the umount to happen, as otherwise its parent filesys, which
might also need unmounting (a tmpfs with devices mounted on a tmpfs that
has none, but is occupying swap, for example.)

Wouldn't this solve the original problem in a much simpler and better way?

kre