[Toybox] [Issue] - mounting a device again

[Ashwini Sharma]

Hi Rob,

What I meant was trying to mount an already mounted device on a different
mountpoint.

In my use case, this is snapshot of my /proc/filesystems
nodev inotifyfs
nodev devpts
ext3
ext4
nodev ramfs

and following is the results when I mount /dev/loop0 (an ext4 formatted
image) on /mnt/one

gvfs-fuse-daemon on /home/ashwini/.gvfs type fuse.gvfs-fuse-daemon
(rw,nosuid,nodev,relatime,user_id=500,group_id=500)
/dev/loop0 on /mnt/one type ext4 (rw,relatime,barrier=1,data=ordered)

Now try to mount the same /dev/loop0 on /mnt/two
result is
# sudo ./toybox mount /dev/loop0 /mnt/two
mount: '/dev/loop0'->'/mnt/two': Device or resource busy

At this point of time, mount tried with ext3 first, got EBUSY and exited.
Whereas it should loop through other filesystems for autodetection
and try to mount with ext4 (in this case) as is present in
/proc/filesystems.

regards,
Ashwini

On Tue, Sep 16, 2014 at 6:20 PM, Rob Landley <rob at landley.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20140917/62ff8487/attachment-0003.htm>