Current-Users archive

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

Re: Fixing swap1_stop

> On 18. Aug 2017, at 10:16, Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
> 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?

A long time ago forced unmounts tried to change open block device nodes
to anonymous (not attached to a file system) nodes.  This was racy and
has been removed.

With the recent changes to the VFS subsystem it should be possible to
bring this behaviour back and instead of destroying open device nodes
a forced unmount would detach them from the file system and keep them

Did you mean something like this?

J. Hannken-Illjes - - TU Braunschweig (Germany)

Home | Main Index | Thread Index | Old Index