Re: the umount() saga for regular linux desktop users

[Andy Lutomirski]

Andries Brouwer wrote:
> On Fri, Dec 31, 2004 at 05:41:02PM +0000, William wrote:
>
>
> > Regularly, when attempting to umount() a filesystem I receive 'device is busy' 
> > errors. The only way (that I have found) to solve these problems is to go on 
> > a journey into processland and kill all the guilty ones that have tied 
> > themselves to the filesystem concerned.
>
>
> Do you know about the existence of the MNT_DETACH flag of umount(2),
> or the -l option of umount(8)?
>
> It seems that does at least some of the things you are asking for.


I have this complaint too, and MNT_DETACH doesn't really do it. 
Sometimes I want to "unmount cleanly, damnit, and I don't care if 
applications that are currently accessing it lose data."  Windows can do 
this, and it's _useful_.

<rant>
I think part of the nastiness is that mount now means too things:
1) Read the superblock, fire up the fs, etc.
2) Shove the thing into the namespace.

The fact that the current mount/umount interface papers over the 
distinction is at least confusing.  It made sense before there were bind 
mounts.  Now, for example, mount /dev/hda2 /mnt/whatever does something 
_different_ depending on whether hda2 is already mounted.  And the mount 
options will be silently ignored sometimes.  Then, I can MNT_DETACH 
something to separate it from the namespace, but I can't force it to 
actually shut down the fs.  There is no interface for it.

Shouldn't these be separate syscalls with separate parameters?  For 
example, ro applied to the fs should mean "don't touch the device" and 
ro applied to the view in the namespace should mean "don't write to this 
view."
</rant>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/