Re: [Toybox] [Issue] - mounting a device again
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
[Toybox] Getting Toybox into Android before the NetBSD userland wins out
Over time, Android has gradually been copying more and more of the NetBSD source code into the Git repository which holds their toolbox command.[*] ^ [*]. See, for example, this change: http://android.googlesource.com/platform/system/core/+/ fd4c6b0a3a25921a9fe24691a695d715aecb6afe I still prefer Toybox. For one thing, the -h help built into various Toybox commands tends to be far better. (Why is the -h help built into various NetBSD commands so skimpy? I guess the developers assume that all users have a manpage viewer installed. Well, Android includes no such viewer.) I think that it would be unwise to wait until Toybox hits 1.0 before trying to get Toybox into Android. The longer the project waits, the better the NetBSD userland will be integrated into Android and the more accustomed the Android team will become to that userland's quirks. I humbly suggest that perhaps the best thing to do would be to visit the Android mailing list today, and to float the idea of getting _some_ parts of Toybox into Android. Perhaps start by suggesting that Toybox could provide some useful things that Android doesn't yet include: for example, dos2unix, unix2dos, nice, renice, sort, uniq, usleep, tac, tee, yes, and acpi. Once Toybox gets into Android, it might then be possible to convince the Android maintainers to provide symlinks from /system/bin to _all_ of the reasonably-finished parts of Toybox. What do you think of my idea? Kind regards, -- Jason Spiro: computer consultant. Improve your kids' or your workers' productivity. If you'd like an Internet filter installed in your home or workplace, contact me today. +1 (416) 992-3445 / http://www.jspiro.com/. ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] Getting Toybox into Android before the NetBSD userland wins out
On Tue, Sep 16, 2014 at 6:23 PM, David Seikel onef...@gmail.com wrote: On Tue, 16 Sep 2014 22:11:41 + (UTC) Jason Spiro jasonspiro4+gm...@gmail.com wrote: Once Toybox gets into Android, it might then be possible to convince the Android maintainers to provide symlinks from /system/bin to _all_ of the reasonably-finished parts of Toybox. What do you think of my idea? This reminds me that I should pull my finger out and put my toybox installer on Play. Please. I have a rooted Android Jellybean tablet with a full Busybox install, but I'd *love* to have Toybox instead. __ Dennis https://plus.google.com/u/0/105128793974319004519 ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] [Issue] - mounting a device again
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
