On Aug 18, 3:16pm, [email protected] (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
