bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

[Olaf Titz]

> So this is a special case of a general problem with no easy solution: What
> should df do when 2 filesystems are mounted at the same location? It can't
> easily give correct information for both of them, since the later mount
> obscures the earlier mount from view.

It is a special case of an even more general problem, that mtab or
/proc/self/mounts and therefore mount(8), df(1) etc. only represent the
linear path where a filesystem was mounted at the time it was mounted,
not the underlying tree structure.

What happens with the following sequences, assuming / is the only
mounted filesystem:

mkdir /mnt/p1
mount /dev/sde1 /mnt/p1
mkdir /mnt/p1/p2
mount /dev/sdh1 /mnt/p1/p2

versus

mkdir -p /mnt/p1/p2
mount /dev/sdh1 /mnt/p1/p2
mount /dev/sde1 /mnt/p1

not that that would be very useful, but in general it is possible. In
the second case the filesystem on sdh1 is completely invisible, yet
mtab and /proc/mounts in both cases contain something like

/dev/sde1 /mnt/p1 ...
/dev/sdh1 /mnt/p1/p2 ...

only in different order: the last mounted filesystem comes last.

This way df(1) should already be able to just hide any obscured
filesystem: it could make two passes over the mount list, remembering
every mount point and if a later mount point is equal or a parent of
an earlier one (which can be determined by a simple string compare),
mark the earlier one as invisible. Then in the second pass over the
list output the remaining mounts.

Remains the question whether this is correct in all cases and actually
desirable behaviour. I think the latter is true, because df(1) output
is just a snapshot of how the system looks like to a newly created
process, and a newly created process can't access the obscured
filesystems at all. (The fact that /proc/mounts is a symlink to
/proc/self/mounts hints in the same direction.)

If what's really wanted is the status of all mounted filesystems
whether visible or not, I fear this can't be done without kernel help,
because exactly by the "snapshot as seen by a new process" nature you
don't get a handle to statfs() from the obscured parts. They can be
found by looking in /sys/block or /proc/diskstats but there doesn't
seem to be useful info, perhaps just another sysfs file containing the
statfs() output would already suffice.

Or perhaps just propose that one of the three nearly-identical
/proc/self/mount* files get two additional columns with the info df(1)
needs...

Olaf