<div dir="ltr">Hi Rob,<div><br></div><div>What I meant was trying to mount an already mounted device on a different mountpoint.</div><div><br></div><div>In my use case, this is snapshot of my /proc/filesystems</div><div><div>nodev<span class="" style="white-space:pre"> </span>inotifyfs</div><div>nodev<span class="" style="white-space:pre"> </span>devpts</div><div><span class="" style="white-space:pre"> </span>ext3</div><div><span class="" style="white-space:pre"> </span>ext4</div><div>nodev<span class="" style="white-space:pre"> </span>ramfs</div></div><div><br></div><div>and following is the results when I mount /dev/loop0 (an ext4 formatted image) on /mnt/one</div><div><br></div><div><div>gvfs-fuse-daemon on /home/ashwini/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=500,group_id=500)</div><div>/dev/loop0 on /mnt/one type ext4 (rw,relatime,barrier=1,data=ordered)</div></div><div><br></div><div>Now try to mount the same /dev/loop0 on /mnt/two</div><div>result is </div><div><div># sudo ./toybox mount /dev/loop0 /mnt/two</div><div>mount: '/dev/loop0'->'/mnt/two': Device or resource busy</div></div><div><br></div><div>At this point of time, mount tried with ext3 first, got EBUSY and exited. Whereas it should loop through other filesystems for autodetection</div><div>and try to mount with ext4 (in this case) as is present in /proc/filesystems.</div><div><br></div><div>regards,<br></div><div>Ashwini</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 16, 2014 at 6:20 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09/15/14 23:14, Ashwini Sharma wrote:<br>
> Hi Rob,<br>
><br>
> Encountered an issue while mounting a device which is already mounted.<br>
><br>
> when __-t__ is not specified, the mount tries with the first device<br>
> filesystem it finds from /proc/filesystems.<br>
<br>
</span>To autodetect filesystem type, yes.<br>
<span class=""><br>
> __mount()__ return an EBUSY, at this point no other file system is tried<br>
> for mounting instead mount breaks out of the loop with a "Device Busy" error.<br>
<br>
</span>With the ubuntu host mount:<br>
<br>
mount -t proc /proc /proc<br>
mount -t proc /proc /proc<br>
mount: proc already mounted<br>
<br>
If the syscall is returning -EBUSY, what is the userspace tool supposed<br>
to do about that?<br>
<span class=""><br>
> Shouldn't it try for another filesystem mount in this case, as this is<br>
> also the behavior from GNU mount.<br>
<br>
</span>A) Does it result in a successful mount?<br>
<br>
B) I thought the gnu version was doing a variant of blkid to try to<br>
identify the filesystem type?<br>
<span class=""><br>
> Use case.<br>
><br>
> Lets have a disk image, formatted ext4 setup at /dev/loop0.<br>
><br>
> mount /dev/loop0 /tmp<br>
><br>
> this mounts loop0 on /tmp with __ext4__<br>
><br>
> try again, mount tries with first fs in /proc/filesystems, e.g. ext3. An<br>
> error is reported and mount breaks out without trying further.<br>
><br>
> What should be the right thing.<br>
<br>
</span>$ truncate -s 1G walrus.img<br>
$ mkfs.ext4 walrus.img<br>
$ sudo mount walrus.img /mnt<br>
$ sudo mount walrus.img /mnt<br>
mount: according to mtab /home/landley/toybox/toybox/walrus.img is<br>
already mounted on /mnt as loop<br>
<br>
I'm open to suggestions but I don't understand the desired behavior?<br>
<br>
Now note that if I mount it over /tmp instead of /mnt it works, even<br>
though /tmp is already a mount point. The kernel objects to placing the<br>
_same_ mount over itself, but stacking mounts is fine.<br>
<br>
I am, however, kind of amused that gnu mount has copied the loop<br>
autodetect stuff I added to busybox in 2006. (Which, at the time, was<br>
the only mount that did that.<br>
<br>
Ah, I see:<br>
<br>
./mount walrus.img /mnt<br>
./mount walrus.img /mnt<br>
/dev/loop0 /mnt ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0<br>
/dev/loop1 /mnt ext4 rw,relatime,user_xattr,barrier=1,data=ordered 0 0<br>
<br>
You're objecting that I'm _not_ autodetecting the existing mount in the<br>
loopback mount case, because loop0 and loop1 are different devices.<br>
However the _kernel_ catches it if I go:<br>
<br>
$ sudo ./mount /dev/loop1 /mnt<br>
mount: '/dev/loop1'->'/mnt': Device or resource busy<br>
<br>
Indeed. I'm sure there are corner cases in this mount command where it's<br>
not doing the right thing yet. I'll try to work out a way to check that.<br>
(The problem is "losetup -j" is using a field that only stores 64 bytes<br>
of information... Oh wait, I can match on device and inode. I think<br>
losetup -j is already doing this right...)<br>
<br>
The _tricky_ bit is that an existing loopback association could have an<br>
offset or size limitation (or encryption, or different -c capacity), so<br>
it might not _be_ quite the same as a fresh losetup. Then again for<br>
autodetect mode, I'm not sure that's our problem?<br>
<br>
(Did I understand your objection correctly?)<br>
<br>
> regards,<br>
> Ashwini<br>
<span class="HOEnZb"><font color="#888888"><br>
Rob<br>
</font></span></blockquote></div><br></div>