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 r...@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
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net