*** Please type your report below this line ***

If an sshfs file system is mounted, then mapped to a different location
in the file system using a bind mount and then the bind mount is unmounted
using the -f (force) flag (as is done for example in /etc/init.d/umountfs),
the sshfs mount breaks:
---
root:~/.ssh# mkdir -p /mnt/mp1
root:~/.ssh# mkdir -p /mnt/mp2
root:~/.ssh# sshfs localhost:/home /mnt/mp1
root:~/.ssh# mount -o bind /mnt/mp1 /mnt/mp2
root:~/.ssh# umount -f /mnt/mp2
root:~/.ssh# ls /mnt/mp1
ls: cannot access /mnt/mp1: Transport endpoint is not connected
---

This is a problem when the bind mount is within a container
(OpenVZ, lxc) and the container runs unmodified init scripts
that unmount the bind mount with the -f flag. It leads to all
other applications and containers to not be able to read
from the sshfs mount any more.

The problem also occurs with glusterfs, the it may be a problem
in the fuse libraries or kernel driver.

Yep, this is how "umount -f" is supposed to work.  You'll get similar
behavior with other network filesystems: NFS, 9P, CEPH, CIFS, etc...

Unfortunately you cannot have an unmodified rc script in the
container in these cases.

Thanks,
Miklos

Am 18.02.2011 schrieb Miklos Szeredi:

With NFS it works.

I don't believe this is how it is supposed to work. Why should an
unmount on a bind mount affect other mounts?

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.

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").

Regards
  Johannes

Sort of, if the server is temporarily down, then you'd see funny stuff
happening in the other mounts too.

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.

That's your interpretation, but the fact is, Linux doesn't work that
way.

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

Am 18.02.2011 schrieb Miklos Szeredi:

If this is true and the way it is supposed to be, why don't we see the
same behaviour with an ext4 mount, for example:
---
/mnt# dd if=/dev/zero of=bigfile count=10240 bs=1024
/mnt# mkfs.ext4 bigfile
/mnt# mkdir -p mp1 mp2
/mnt# mount -o loop -t ext4 bigfile mp1
/mnt# mount -o bind mp1 mp2
/mnt# touch mp1/x
/mnt# ls mp2
lost+found  x
/mnt# ls mp1
lost+found  x
/mnt# umount -f mp2
/mnt# ls mp1
lost+found  x
---

Regards
  Johannes

Is there any chance this problem will be solved anytime soon?