Re: df: use mountinfo from /proc on Linux

[Fridolin Pokorny]

On Monday 25 August 2014 18:40:10 Pádraig Brady wrote:
> 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.

Proposing the patch. A gnulib patch was already proposed [1].

Have a nice day!
Fridolin Pokorny

[1] http://lists.gnu.org/archive/html/bug-gnulib/2014-08/msg00039.html

0001-df-avoid-stat-s-when-using-proc-PID-mountinfo.patch
Description: Text Data