[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <467994BD.6000403@zytor.com>
Date: Wed, 20 Jun 2007 13:57:33 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel@...r.kernel.org, util-linux-ng@...r.kernel.org
Subject: Adding subroot information to /proc/mounts, or obtaining that through
other means
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists