From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Adding subroot information to /proc/mounts, or obtaining that through other means Date: Wed, 20 Jun 2007 13:57:33 -0700 Message-ID: <467994BD.6000403@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit To: Linux Kernel Mailing List , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, util-linux-ng-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Return-path: Sender: util-linux-ng-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org 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