Re: df: use mountinfo from /proc on Linux

[Pádraig Brady]

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.