Bug#613904: sshfs in combination with bind mounts and umount -f fails
Johannes Martin
Package: sshfs
Version: 2.2-1
Severity: normal
*** 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.
-- System Information:
Debian Release: 6.0
APT prefers squeeze-updates
APT policy: (500, 'squeeze-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages sshfs depends on:
ii fuse-utils 2.8.4-1.1 Filesystem in USErspace
(utilities
ii libc6 2.11.2-10 Embedded GNU C Library:
Shared lib
ii libfuse2 2.8.4-1.1 Filesystem in USErspace library
ii libglib2.0-0 2.24.2-1 The GLib library of C routines
ii openssh-client 1:5.5p1-6 secure shell (SSH) client,
for sec
sshfs recommends no packages.
sshfs suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Miklos Szeredi
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
Johannes Martin
Just verified, yes, it happens with CIFS, too.
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
Miklos Szeredi
> 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
Johannes Martin
>> 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.
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