On 08/25/2014 06:23 PM, Fridolin Pokorny wrote: > On Wednesday 20 August 2014 16:21:27 Pádraig Brady wrote: >> On 08/20/2014 03:53 PM, Fridolin Pokorny wrote: >>> Hi, >>> >>> I am about to implement /proc/self/mountinfo support for df. This feature >>> is marked as TODO in sources. I have found a suitable parser provided by >>> libmount from util-linux [1]. This could be the best option here in my >>> opinion. >>> >>> The change might also reflect gnulib. Items in mount entries (struct >>> mount_entry from mountlist.h) should be propagated from libmount. >>> >>> I want to know if such change will be accepted. Do you have any additional >>> notes to discuss? >>> >>> Have a nice day, >>> Fridolin Pokorny. >>> >>> [1] http://git.kernel.org/cgit/utils/util-linux/util-linux.git >> >> Note the kernel processing to generate /proc/self/mountinfo is significant, >> so ideally gnulib's read_file_system_list() would read that once (falling >> back to /etc/mtab if not available). > > Agreed. > >> There is more info in /proc/$$/mountinfo wrt bind mounts etc. >> and I've yet to look into if any of that is useful for df. > > I went through kernel sources and I cannot find any difference in generated > output. Accessing /proc/self is treated as accessing /proc/$$. I saw that > there are used exclusive locks when accessing /proc/self, which will be good > to omit by using /proc/$$. > > There can be found info about shared subtrees and parent mount IDs among > others in /proc/$$/mountinfo. I don't know if either of this could be useful > for df. > >> I'd come up with a concrete set of advantages of using libmount before >> proceeding. Avoid stat()s may not warrant the change. > > The biggest advantage for me is that mount ID could be propagated from /proc > instead of using stat()s: > > # mkdir /chroot/home > # mount /dev/sda1 /chroot/home > # mount /dev/sda2 /home > # df > ... > /dev/sda1 - - - -% /chroot/home > /dev/sda2 - - - -% /home > ... > # mount -t proc proc /chroot/proc/ > # chroot /chroot > chroot# df > ... > /dev/sda2 - - - -% /home > ... > > There should be /dev/sda1. > > Filesystems mounted outside of chroot are not displayed in > /proc/$$/mountinfo. > Now df prints errors complaining ENOENT when filesystems are not accessible > inside chroot. > > Another bogus output for me could be simulated by creating directory with same > name as mountpoint outside of chroot. > > chroot# ls /run > ls: cannot access /run: No such file or directory > chroot# df > ... > df: '/run': No such file or directory > ... > chroot# mkdir /run > chroot# df -a > ... > tmpfs - - - -% /run > ... > > In all cases above, mountpoints are in mount namespace of the current > process, > but they are not accessible due to chroot. All of this can be improved by > using /proc/$$/mountinfo.
Thanks for investigating. With both the performance and correctness advantages doing this is worthwhile. cheers, Pádraig.
