On Fri, 18 Feb 2011, Johannes Martin wrote:
> Just verified, yes, it happens with CIFS, too.
>
> With NFS it works.
Sort of, if the server is temporarily down, then you'd see funny stuff
happening in the other mounts too.
> I don't believe this is how it is supposed to work. Why should an
> unmount on a bind mount affect other mounts?
Because they share a common super block. Non forced unmounts indeed
don't affect other mounts since they only detach the mount from the
namespace and do not actually call into the filesystem in any way.
Forced umounts, on the other hand, do call into the filesystem and
instruct it to abort any outstanding requests so the umount can
proceed even if the server is dead.
I think it's pretty clear that you do not want this behavior for the
shutdown script in the container. So just fix the script not to call
umount with the -f flag if it's running on non-native hardware.
>
> The docs say (man 2 umount):
> MNT_FORCE (since Linux 2.1.116)
> Force unmount even if busy. This can cause data loss. (Only
> for NFS mounts.)
>
> So the -f flag should only make a difference if a filesystem is busy,
> and even then it should not affect other mount points.
That's your interpretation, but the fact is, Linux doesn't work that
way.
> I'm not unmounting the original mount and complain that the bind mount
> no longer works (that would in fact make sense with umount -f). It's the
> other way around: I'm unmounting something that happens to bind mount a
> directory lying on an sshfs file system to somewhere else and it causes
> the underlying mount to break ("mount" still lists the mount to be
> active, and so does "/proc/mounts").
There's no distinction between original mount and bind mount in Linux.
>From the kernel's point of view they are completely equal.
Thanks,
Miklos
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
