[Toybox] [Issue] - mounting a device again

[Rob Landley]

On 09/15/14 23:14, Ashwini Sharma wrote:
> Hi Rob,
> 
> Encountered an issue while mounting a device which is already mounted.
> 
> when __-t__ is not specified, the mount tries with the first device
> filesystem it finds from /proc/filesystems. 

To autodetect filesystem type, yes.

> __mount()__ return an EBUSY, at this point no other file system is tried
> for mounting instead mount breaks out of the loop with a "Device Busy" error.

With the ubuntu host mount:

mount -t proc /proc /proc
mount -t proc /proc /proc
mount: proc already mounted

If the syscall is returning -EBUSY, what is the userspace tool supposed
to do about that?

> Shouldn't it try for another filesystem mount in this case, as this is
> also the behavior from GNU mount.

A) Does it result in a successful mount?

B) I thought the gnu version was doing a variant of blkid to try to
identify the filesystem type?

> Use case.
> 
> Lets have a disk image, formatted ext4 setup at /dev/loop0.
> 
> mount /dev/loop0 /tmp
> 
> this mounts loop0 on /tmp with __ext4__
> 
> try again, mount tries with first fs in /proc/filesystems, e.g. ext3. An
> error is reported and mount breaks out without trying further.
> 
> What should be the right thing.

$ truncate -s 1G walrus.img
$ mkfs.ext4 walrus.img
$ sudo mount walrus.img /mnt
$ sudo mount walrus.img /mnt
mount: according to mtab /home/landley/toybox/toybox/walrus.img is
already mounted on /mnt as loop

I'm open to suggestions but I don't understand the desired behavior?

Now note that if I mount it over /tmp instead of /mnt it works, even
though /tmp is already a mount point. The kernel objects to placing the
_same_ mount over itself, but stacking mounts is fine.

I am, however, kind of amused that gnu mount has copied the loop
autodetect stuff I added to busybox in 2006. (Which, at the time, was
the only mount that did that.

Ah, I see:

./mount walrus.img /mnt
./mount walrus.img /mnt
/dev/loop0 /mnt ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0
/dev/loop1 /mnt ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0

You're objecting that I'm _not_ autodetecting the existing mount in the
loopback mount case, because loop0 and loop1 are different devices.
However the _kernel_ catches it if I go:

$ sudo ./mount /dev/loop1 /mnt
mount: '/dev/loop1'->'/mnt': Device or resource busy

Indeed. I'm sure there are corner cases in this mount command where it's
not doing the right thing yet. I'll try to work out a way to check that.
(The problem is "losetup -j" is using a field that only stores 64 bytes
of information... Oh wait, I can match on device and inode. I think
losetup -j is already doing this right...)

The _tricky_ bit is that an existing loopback association could have an
offset or size limitation (or encryption, or different -c capacity), so
it might not _be_ quite the same as a fresh losetup. Then again for
autodetect mode, I'm not sure that's our problem?

(Did I understand your objection correctly?)

> regards,
> Ashwini

Rob

 1410871809.0