Re: Fixing swap1_stop

[christos%zoulas.com@localhost (Christos Zoulas)]

On Aug 18,  3:16pm, kre%munnari.OZ.AU@localhost (Robert Elz) wrote:
-- Subject: Re: Fixing swap1_stop

I think Hannken can answer this...

christos

| 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
-- End of excerpt from Robert Elz