Adding subroot information to /proc/mounts, or obtaining that throughother means

[H. Peter Anvin]

Right now it is actually impossible to conclusively determine a
filesystem-relative path in the presence of bind (and possibly move)
mounts.  This is highly desirable to be able to do in contexts that
involve non-Linux (or not-the-current-instance-of-Linux) accesses to the
filesystem, e.g. other filesystems or bootloaders.

Example:

Let's assume /dev/md6 is mounted on /export.  Then /export/users/foo and
/exports/users/bar are bind-mounted to /home/foo and /home/bar respectively.

/proc/mounts will show:

/dev/md6 /export ext3 rw,data=ordered 0 0
/dev/md6 /home/foo ext3 rw,data=ordered 0 0
/dev/md6 /home/bar ext3 rw,data=ordered 0 0

... with no indication that anything is amiss.  The latter two fields
are confusing, at best.

We could add a field to /proc/mounts to add this information:

/dev/md6 /export ext3 rw,data=ordered 0 0 /
/dev/md6 /home/foo ext3 rw,data=ordered 0 0 /users/foo
/dev/md6 /home/bar ext3 rw,data=ordered 0 0 /users/bar

... or, alternatively, add a subfield to the first field (which would
entail escaping whatever separator we choose):

/dev/md6 /export ext3 rw,data=ordered 0 0
/dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0
/dev/md6:/users/bar /home/bar ext3 rw,data=ordered 0 0

One could also consider providing a system call (or ioctl, ...) to get
this information, effectively as an augmentation to stat().  If that's
the case, it would probably be a good thing if this "stat-plus" system
call could in the future be expanded to contain additional information
without having to change a structure every time, perhaps using a method
similar to sendmsg/recvmsg, as ugly as those are.

I'm personally leaning toward the second option (/dev/md6:/users/foo).
Although that might confuse current utilities, those utilities are
*already* liable to get confused by the fact that the line doesn't mean
what they think it means.

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/