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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
