On Wed, Aug 24, 2011 at 4:09 AM, Robert Connolly
<rob...@linuxfromscratch.org> wrote:
> On Tuesday 23 August 2011 17:31:20 Kevin Day wrote:
>> On Mon, Aug 22, 2011 at 11:53 PM, Robert Connolly
>>
>> <rob...@linuxfromscratch.org> wrote:
>> > On Monday 22 August 2011 18:46:54 Kevin Day wrote:
>> >> I find /etc/mtab to be of poor taste.
>> >> I have a bunch of patches that fix software to use /proc/mounts and
>> >> not /etc/mtab.
>> >> Thus leaving all of the mounted device listing to the kernel (who is
>> >> always correct).
>> >> Then there is no need to worry about clobbering /etc/mtab. (especially
>> >> if your on a read-only or limited-write system).
>> >
>> > Can I see your patches for util-linux-ng? Or all the patches?
>> >
>> > robert
>>
>> I am attaching it, hopefully it does not get blocked.
>> The following programs need patches to use /proc/mounts
>> - eject
>> - glib
>> - samba (it tries to do writes to /etc/mtab itself!)
>> - util-linux-ng
>> - xine-lib
>> - uClibc (yep, i still use it for better and worse)
>> - glibc
>>
>> Any application that properly uses the libc's _PATH_MOUNTED should not
>> need to be patched but should obviously need to be
>> installed/reinstalled after applying the glibc/uclibc patch.
>
> There's a thread from Debian about /etc/mtab:
> http://lists.debian.org/debian-devel/2002/06/msg01831.html
>
> /proc/mounts doesn't have all the information about loop device mounts, so
> umounting a loop device wouldn't break down the loop device after.
>
> This is a disadvantage.
>
> robert
I'm not so sure about that.
My custom-build exclusively uses squashfs for all of my binaries
mounted through loopback.
I have never noticed problems with unmounting a loop back device in this manner.
The loopback devices always appears to be available again after an umount.
Basic example:
$ df -haT
Filesystem Type Size Used Avail Use% Mounted on
/dev/loop0
squashfs 83M 83M 0 100% /bin
/dev/loop1
squashfs 143M 143M 0 100% /lib
/dev/loop2
squashfs 22M 22M 0 100% /sbin
/dev/loop3
squashfs 210M 210M 0 100% /share
And this includes filesystems like fuse (the below example replaces
the real hostname with www.google.com):
www.google.com:/
fuse.sshfs 0.0K 0.0K 0.0K - /remote_system
And the /proc/mounts for the above mounts looks like:
/dev/loop0 /bin squashfs ro,relatime 0 0
/dev/loop1 /lib squashfs ro,relatime 0 0
/dev/loop2 /sbin squashfs ro,relatime 0 0
/dev/loop3 /share squashfs ro,relatime 0 0
www.google.com:/ /remote_system fuse.sshfs
rw,nosuid,nodev,relatime,user_id=6000,group_id=6000,max_read=65536 0 0
Looking at the following post from your reference:
- http://lists.debian.org/debian-devel/2002/06/msg01834.html
Parts of /etc/mtab:
===================
/mnt/hdb/31/cdimages/potato1.iso /mnt/iso/potato1 iso9660 ro,loop=/dev/loop0 0 0
The same from /proc/mounts:
===========================
/dev/loop0 /mnt/iso/potato1 iso9660 ro 0 0
The first part /mnt/hdb/31/cdimages/potato1.iso already exists in the
kernel, your just looking in the wrong spot.
For /dev/loop0, see:
- /sys/devices/virtual/block/loop0
- /sys/devices/virtual/block/loop0/loop/backing_file
The backing_file contains the path to the mount point and would
contain something like: /mnt/hdb/31/cdimages/potato1.iso
This leaves me with the following questions & statements:
- What other information is missing that is traditionally expected to
be read from /etc/mtab ?
- The www.google.com message shows that custom/specific information
can be given to the kernel without any issues.
- Is this specific to fuse filesystems?
- I've never had problems with mount -o remount,some_new_settings
/some/path/or/device when using /proc/mounts
- If anything, we get MORE information from /proc/mounts because we
now know exactly which loopback device is used which can then tell us
what the backing_file is. With the mtab approach, if the specific
loopback device was not passed as an "options" argument, then there
would be no way to know which loopback device is being used.
- At the time of the articles I am not sure /sys/ existed in the
kernel, so while the kernel did know of the backing_file and whatnot,
it may not have told anybody or given any way to find out.
- losetup -a also gives information about lookpback devices.
--
Kevin Day
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
