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

Adding subroot information to /proc/mounts, or obtaining that through other 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

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Al Viro]

On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
> ... 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

Hell, no.  The first field is in principle impossible to parse unless
you know the fs type.

How about making a new file with sane format?  From the very
beginning.  E.g. mountpoint + ID + relative path + type + options,
where ID uniquely identifies superblock (e.g. numeric st_dev)
and backing device (if any) is sitting among the options...

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Al Viro wrote:
> On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
>> ... 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
> 
> Hell, no.  The first field is in principle impossible to parse unless
> you know the fs type.
> 
> How about making a new file with sane format?  From the very
> beginning.  E.g. mountpoint + ID + relative path + type + options,
> where ID uniquely identifies superblock (e.g. numeric st_dev)
> and backing device (if any) is sitting among the options...

Okay, I see there has been some discussion on this earlier, based on a
proposal by Ram Pai, so it pretty much comes down to redesigning this
right.  I see some issues with his proposal (device numbers exported to
userspace in text form should be separated into major:minor form, for
one thing.)  I know the util-linux-ng people have also had issues with
/proc/mounts that they would like resolved in order to finally nuke
/etc/mtab.

Is Ram still working on this?  I'd like to help make this happen so we
can be done with it.

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Ram Pai]

On Wed, 2007-06-20 at 14:20 -0700, H. Peter Anvin wrote:
> Al Viro wrote:
> > On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
> >> ... 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
> > 
> > Hell, no.  The first field is in principle impossible to parse unless
> > you know the fs type.
> > 
> > How about making a new file with sane format?  From the very
> > beginning.  E.g. mountpoint + ID + relative path + type + options,
> > where ID uniquely identifies superblock (e.g. numeric st_dev)
> > and backing device (if any) is sitting among the options...
> 
> Okay, I see there has been some discussion on this earlier, based on a
> proposal by Ram Pai, so it pretty much comes down to redesigning this
> right.  I see some issues with his proposal (device numbers exported to
> userspace in text form should be separated into major:minor form, for
> one thing.)  I know the util-linux-ng people have also had issues with
> /proc/mounts that they would like resolved in order to finally nuke
> /etc/mtab.
> 
> Is Ram still working on this?  I'd like to help make this happen so we
> can be done with it.

Peter, I am not working on it currently. But i am interested in getting
it done. I have the seed set of patches which had Al Viro's ideas
incorporated. Infact those patches were sent on lkml 2 months back.
Shall we start with those patches?

RP


> 
> 	-hpa
> 
> 

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Ram Pai wrote:
> 
> Peter, I am not working on it currently. But i am interested in getting
> it done. I have the seed set of patches which had Al Viro's ideas
> incorporated. Infact those patches were sent on lkml 2 months back.
> Shall we start with those patches?
> 

Are these the "unprivileged mount syscall" patches?

Otherwise I don't see any patches in my personal LKML cache (apparently
my subscription to fsdevel was dropped at some point, so I don't have a
stash of it.)

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Ram Pai]

On Thu, 2007-06-21 at 09:29 -0700, H. Peter Anvin wrote:
> Ram Pai wrote:
> > 
> > Peter, I am not working on it currently. But i am interested in getting
> > it done. I have the seed set of patches which had Al Viro's ideas
> > incorporated. Infact those patches were sent on lkml 2 months back.
> > Shall we start with those patches?
> > 
> 
> Are these the "unprivileged mount syscall" patches?

no. but those patches were sent in the same thread. Karel had provided
suggestions which I am yet to incorporate.

Give me today. I will send out the patches incorporating the comment
later in the evening.

ok?
RP

> 
> Otherwise I don't see any patches in my personal LKML cache (apparently
> my subscription to fsdevel was dropped at some point, so I don't have a
> stash of it.)


> 
> 	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Ram Pai wrote:
> 
> Peter, I am not working on it currently. But i am interested in getting
> it done. I have the seed set of patches which had Al Viro's ideas
> incorporated. Infact those patches were sent on lkml 2 months back.
> Shall we start with those patches?
> 

Okay, so what I see in your patches are:

> > path-from-root: mount point of the mount from /
> > path-from-root-of-its-sb: path from its own root dentry.
> > propagation-flag: SHARED, SLAVE, UNBINDABLE, PRIVATE
> > peer-mount-id: the mount-id of its peer mount (if this mount is shared)
> > master-mount-id: the mount-id of its master mount (if this mount is
slave)

Other than cosmetic, I don't see anything terribly wrong with this,
although getting a flag when the directory is overmounted would be nice.

I guess I suggest a single comma-separated field with flags and optional
":argument":

	private
	shared:<peer>
	slave:<master>
	unbindable
	overmounted

So we could end up with something like:

rootfs / rootfs rw 0 0 0:1 / 1 private,overmounted

... where 1 is the mnt_id (sequence number).

[Please see my other comments in this thread... basically I believe we
should just add fields to /proc/mounts.]

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

H. Peter Anvin wrote:
> 
> I guess I suggest a single comma-separated field with flags and optional
> ":argument":
> 
> 	private
> 	shared:<peer>
> 	slave:<master>
> 	unbindable
> 	overmounted
> 

Just realized: overmounted should presumably have a mount ID associated
with it, too.

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Ram Pai]

On Thu, 2007-06-21 at 10:31 -0700, H. Peter Anvin wrote:
> Ram Pai wrote:
> > 
> > Peter, I am not working on it currently. But i am interested in getting
> > it done. I have the seed set of patches which had Al Viro's ideas
> > incorporated. Infact those patches were sent on lkml 2 months back.
> > Shall we start with those patches?
> > 
> 
> Okay, so what I see in your patches are:
> 
> > > path-from-root: mount point of the mount from /
> > > path-from-root-of-its-sb: path from its own root dentry.
> > > propagation-flag: SHARED, SLAVE, UNBINDABLE, PRIVATE
> > > peer-mount-id: the mount-id of its peer mount (if this mount is shared)
> > > master-mount-id: the mount-id of its master mount (if this mount is
> slave)
> 
> Other than cosmetic, I don't see anything terribly wrong with this,
> although getting a flag when the directory is overmounted would be nice.
> 
> I guess I suggest a single comma-separated field with flags and optional
> ":argument":
> 
> 	private
> 	shared:<peer>
> 	slave:<master>
> 	unbindable
> 	overmounted
> 
> So we could end up with something like:
> 
> rootfs / rootfs rw 0 0 0:1 / 1 private,overmounted
> 
> ... where 1 is the mnt_id (sequence number).
> 
> [Please see my other comments in this thread... basically I believe we
> should just add fields to /proc/mounts.]

I had two patches. The first patch added a new interface
called /proc/mounts_new  and had the following format.

FSID  mntpt  root-dentry  fstype fs-options

where FSID is a filesystem unique id
mntpt is the path to the mountpoint
root-dentry is the path to the dentry with respect to the root dentry of
the same filesystem.
fstype  is the filesystem type
fs-options  the mount options used.


the second patch made a /proc/propagation interface which had almost the
same fields, but also added fields to show the propagation type of the
mount as well as pointers to its peers and master depending on the type
of the mount. 

I think the consensus seems to have a new interface /proc/make-a-name
which extends the interface provided by /proc/mounts but provides the
propagation state of the mounts too as well as disambiguate bind mounts.
Which makes sense.

Why not have something like this?

mnt-id FSID backing-dev mntpt root-dentry fstype
comma-separated-fs-options

and one of the fields in the comma-separated-fs-options indicates the
propagation type of the mount.


BTW: what is the need for overmounted flag?  Do you mean two vfsmounts
mounted on the same dentry on the ***same vfsmount*** ?


RP










> 
> 	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Ram Pai wrote:
> 
> the second patch made a /proc/propagation interface which had almost the
> same fields, but also added fields to show the propagation type of the
> mount as well as pointers to its peers and master depending on the type
> of the mount. 
> 
> I think the consensus seems to have a new interface /proc/make-a-name
> which extends the interface provided by /proc/mounts but provides the
> propagation state of the mounts too as well as disambiguate bind mounts.
> Which makes sense.
> 

Why?  It seems a lot cleaner to have all the information in the same
place.  It is highly unfriendly to userspace to have to gather
information in a lot of places, plus it adds race conditions.

It would be another matter if the format that we have now couldn't be
extended, but we need those fields (well, except the two zeros, but who
cares) *anyway*, so we might as well stick to the existing file, and
reduce the total amount of code and clutter.

> 
> BTW: what is the need for overmounted flag?  Do you mean two vfsmounts
> mounted on the same dentry on the ***same vfsmount*** ?
> 

Maybe I'm not following the uses of your flags well enough to figure out
 if that information can already been deduced.

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Ram Pai]

On Fri, 2007-06-22 at 00:06 -0700, H. Peter Anvin wrote:
> Ram Pai wrote:
> > 
> > the second patch made a /proc/propagation interface which had almost the
> > same fields, but also added fields to show the propagation type of the
> > mount as well as pointers to its peers and master depending on the type
> > of the mount. 
> > 
> > I think the consensus seems to have a new interface /proc/make-a-name
> > which extends the interface provided by /proc/mounts but provides the
> > propagation state of the mounts too as well as disambiguate bind mounts.
> > Which makes sense.
> > 
> 
> Why?  It seems a lot cleaner to have all the information in the same
> place.  It is highly unfriendly to userspace to have to gather
> information in a lot of places, plus it adds race conditions.
> 
> It would be another matter if the format that we have now couldn't be
> extended, but we need those fields (well, except the two zeros, but who
> cares) *anyway*, so we might as well stick to the existing file, and
> reduce the total amount of code and clutter.

Ok. so you think /proc/mounts can be extended easily without breaking
any userspace commands?

well lets see..
1. to disambiguate bind mounts, we have to add a field that displays the
	 path to the mount's root dentry from the filesystem's root
	 dentry. Agree?

2. For filesystems that do not have a backing store, it becomes hard
	to disambiguate bind mounts in (1). So we need to add a
	filesystem-id field.

3. if we need to add the propagation status of the mount we need a
	 propagation flag added in the output.

4. To be able to construct the propagation tree, we need a way to refer
	to the other mounts, since some mounts are peers and some other
	mounts are master. Which means we need a mount-id field.
	Agree?

If you agree to the above 4 new fields, it becomes challenging to
extend /proc/mounts to incorporate these new fields without
breaking any existing applications. 


> > 
> > BTW: what is the need for overmounted flag?  Do you mean two vfsmounts
> > mounted on the same dentry on the ***same vfsmount*** ?
> > 
> 
> Maybe I'm not following the uses of your flags well enough to figure out
>  if that information can already been deduced.

With the addition of the above 4 mentioned fields, I think one should be
easily able to decipher which mnt-id is mounted on which mnt-id. no?
maybe not. Well we will have to extend the mountpoint field to indicate
the mnt-id in which the mountpoint resides.  

RP

> 
> 	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Ram Pai wrote:
> 
> Ok. so you think /proc/mounts can be extended easily without breaking
> any userspace commands?
> 
> well lets see..
> 1. to disambiguate bind mounts, we have to add a field that displays the
> 	 path to the mount's root dentry from the filesystem's root
> 	 dentry. Agree?
> 
> 2. For filesystems that do not have a backing store, it becomes hard
> 	to disambiguate bind mounts in (1). So we need to add a
> 	filesystem-id field.
> 
> 3. if we need to add the propagation status of the mount we need a
> 	 propagation flag added in the output.
> 
> 4. To be able to construct the propagation tree, we need a way to refer
> 	to the other mounts, since some mounts are peers and some other
> 	mounts are master. Which means we need a mount-id field.
> 	Agree?
> 
> If you agree to the above 4 new fields, it becomes challenging to
> extend /proc/mounts to incorporate these new fields without
> breaking any existing applications. 
> 

No, I don't think so.  I suspect, in fact, that as long as we add the
new fields to the right (obviously) we should be fine.  There aren't all
that many users of /proc/mounts, and even fewer that don't use the
library functions (getmntent et al.)

	-hpa

[RFC PATCH 1/1] VFS: Augment /proc/mount with subroot and shared-subtree

[Ram Pai]

Please check if the following modified patch meets the requirements.

It augments /proc/mount with additional information to
	(1) disambiguate bind mounts with subroot information.
	(2) display shared-subtree information using which one can
		determine the propagation trees.


The following additional fields are appended to each record
in /proc/mounts

mntid=id    ->  The unique id associated with that mount.
fsid=id:dir ->  The filesystem's id and directory in that filesystem
that
		makes the root directory of this mount.
parent=id   ->  The id of the mount's parent; on which it is mounted.

also flags are augmented with new information to indicate the mount's 
propagation type.

Here is a sample 'cat /proc/mounts' after executing the following
commands:
mount --bind /mnt /mnt
mount --make-shared /mnt
mount --bind /mnt/1 /var
mount --make-slave /var
mount --make-shared /mnt
mount --make-unbindable /proc

rootfs / rootfs rw PRIVATE mntid=c1708c30 fsid=1:/ parent=c1708c30 0 0
/dev/root / ext2 rw  PRIVATE mntid=c1208c08 fsid=6200:/ parent=c1708c30
0 0
/proc /proc proc rw UNBINDABLE mntid=c1108c90 fsid=3:/ parent=c1208c08 0
0
devpts /dev/pts devpts rw PRIVATE mntid=c1108c18 fsid=a:/
parent=c1208c08 0 0
/dev/root /mnt ext2 rw  SHARED:peer=c1e08cb0 mntid=c1e08cb0
fsid=6200:/mnt parent=c1208c08 0 0
/dev/root /var ext2 rw  SHARED:peer=c1f08c28 SLAVE:master=c1e08cb0
mntid=c1f08c28 fsid=6200:/mnt/1 parent=c1208c08 0 0


For example, the last line indicates that 
The mount is a shared mount.
Its peer mount is itself (note peer=c1f08c28 is the same mntid as
itself).
It is also a slave mount of the mount with the id c1e08cb0.  
The filesystem with fsid=6200 and subdirectory mnt/1 makes the root
directory 
	of this mount.
And finally the mount with id c1208c08 is its parent.


Signed-off-by: Ram Pai <linuxram@us.ibm.com>

---
 fs/dcache.c              |   53 +++++++++++++++++++++++++++++++
 fs/namespace.c           |   25 ++++++++++++++
 fs/pnode.c               |   22 +++++++++++++
 fs/pnode.h               |    2 +
 fs/seq_file.c            |   79
++++++++++++++++++++++++++++++++++-------------
 include/linux/dcache.h   |    2 +
 include/linux/seq_file.h |    1 
 7 files changed, 162 insertions(+), 22 deletions(-)

Index: linux-2.6.21.5/fs/dcache.c
===================================================================
--- linux-2.6.21.5.orig/fs/dcache.c
+++ linux-2.6.21.5/fs/dcache.c
@@ -1835,6 +1835,59 @@ char * d_path(struct dentry *dentry, str
 	return res;
 }

+static inline int prepend(char **buffer, int *buflen, const char *str,
+					int namelen)
+{
+	if ((*buflen -= namelen) < 0)
+		return 1;
+	*buffer -= namelen;
+	memcpy(*buffer, str, namelen);
+	return 0;
+}
+
+/*
+ * write full pathname into buffer and return start of pathname.
+ * If @vfsmnt is not specified return the path relative to the
+ * its filesystem's root.
+ */
+char * dentry_path(struct dentry *dentry, char *buf, int buflen)
+{
+	char * end = buf+buflen;
+	char * retval;
+
+	spin_lock(&dcache_lock);
+	prepend(&end, &buflen, "\0", 1);
+	if (!IS_ROOT(dentry) && d_unhashed(dentry)) {
+		if (prepend(&end, &buflen, "//deleted", 10))
+			goto Elong;
+	}
+	/* Get '/' right */
+	retval = end-1;
+	*retval = '/';
+
+	for (;;) {
+		struct dentry * parent;
+		if (IS_ROOT(dentry))
+			break;
+
+		parent = dentry->d_parent;
+		prefetch(parent);
+
+		if (prepend(&end, &buflen, dentry->d_name.name,
+				dentry->d_name.len) ||
+	            prepend(&end, &buflen, "/", 1))
+			goto Elong;
+
+		retval = end;
+		dentry = parent;
+	}
+	spin_unlock(&dcache_lock);
+	return retval;
+Elong:
+	spin_unlock(&dcache_lock);
+	return ERR_PTR(-ENAMETOOLONG);
+}
+
 /*
  * NOTE! The user-level library version returns a
  * character pointer. The kernel system call just
Index: linux-2.6.21.5/fs/namespace.c
===================================================================
--- linux-2.6.21.5.orig/fs/namespace.c
+++ linux-2.6.21.5/fs/namespace.c
@@ -386,8 +386,31 @@ static int show_vfsmnt(struct seq_file *
 		if (mnt->mnt_flags & fs_infop->flag)
 			seq_puts(m, fs_infop->str);
 	}
-	if (mnt->mnt_sb->s_op->show_options)
+	seq_putc(m, ' ');
+	if (mnt->mnt_sb->s_op->show_options) {
 		err = mnt->mnt_sb->s_op->show_options(m, mnt);
+		seq_putc(m, ' ');
+	}
+	if (IS_MNT_SHARED(mnt)) {
+		seq_printf(m, "%s:peer=%x ", "SHARED",
+				new_encode_dev((int)get_peer_same_ns(mnt)));
+		if (IS_MNT_SLAVE(mnt)) {
+			seq_printf(m, "%s:master=%x ", "SLAVE",
+				new_encode_dev((int)get_master_same_ns(mnt)));
+		}
+	} else if (IS_MNT_SLAVE(mnt)) {
+		seq_printf(m, "%s:master=%x ", "SLAVE",
+			new_encode_dev((int)get_master_same_ns(mnt)));
+	} else if (IS_MNT_UNBINDABLE(mnt)) {
+		seq_printf(m, "%s ", "UNBINDABLE");
+	} else {
+		seq_printf(m, "%s ", "PRIVATE");
+	}
+	seq_printf(m, "mntid=%x fsid=%x:", new_encode_dev((int)mnt),
+				new_encode_dev((int)mnt->mnt_sb->s_dev));
+	seq_dentry(m, mnt->mnt_root, " \t\n\\");
+	seq_putc(m, ' ');
+	seq_printf(m, "parent=%x", new_encode_dev((int)mnt->mnt_parent));
 	seq_puts(m, " 0 0\n");
 	return err;
 }
Index: linux-2.6.21.5/fs/seq_file.c
===================================================================
--- linux-2.6.21.5.orig/fs/seq_file.c
+++ linux-2.6.21.5/fs/seq_file.c
@@ -338,38 +338,75 @@ int seq_printf(struct seq_file *m, const
 }
 EXPORT_SYMBOL(seq_printf);

-int seq_path(struct seq_file *m,
-	     struct vfsmount *mnt, struct dentry *dentry,
-	     char *esc)
+static inline char *mangle_path(char *s, char *p, char *esc)
 {
+	while (s <= p) {
+		char c = *p++;
+		if (!c) {
+			return s;
+		} else if (!strchr(esc, c)) {
+			*s++ = c;
+		} else if (s + 4 > p) {
+			break;
+		} else {
+			*s++ = '\\';
+			*s++ = '0' + ((c & 0300) >> 6);
+			*s++ = '0' + ((c & 070) >> 3);
+			*s++ = '0' + (c & 07);
+		}
+	}
+	return NULL;
+}
+
+/*
+ * return the absolute path of 'dentry' residing in mount 'mnt'.
+ */
+int seq_path(struct seq_file *m, struct vfsmount *mnt, struct dentry
*dentry,
+ 	     char *esc)
+{
+	char *p = NULL;
 	if (m->count < m->size) {
 		char *s = m->buf + m->count;
-		char *p = d_path(dentry, mnt, s, m->size - m->count);
+		p = d_path(dentry, mnt, s, m->size - m->count);
 		if (!IS_ERR(p)) {
-			while (s <= p) {
-				char c = *p++;
-				if (!c) {
-					p = m->buf + m->count;
-					m->count = s - m->buf;
-					return s - p;
-				} else if (!strchr(esc, c)) {
-					*s++ = c;
-				} else if (s + 4 > p) {
-					break;
-				} else {
-					*s++ = '\\';
-					*s++ = '0' + ((c & 0300) >> 6);
-					*s++ = '0' + ((c & 070) >> 3);
-					*s++ = '0' + (c & 07);
-				}
+			s = mangle_path(s, p, esc);
+			if (s) {
+				p = m->buf + m->count;
+				m->count = s - m->buf;
+				return s - p;
 			}
 		}
 	}
 	m->count = m->size;
-	return -1;
+	return p == ERR_PTR(-ENAMETOOLONG) ? 0 : -1;
 }
+
 EXPORT_SYMBOL(seq_path);

+/*
+ * returns the path of the 'dentry' from the root of its filesystem.
+ */
+int seq_dentry(struct seq_file *m, struct dentry *dentry, char *esc)
+{
+	char *p = NULL;
+	if (m->count < m->size) {
+		char *s = m->buf + m->count;
+		p = dentry_path(dentry, s, m->size - m->count);
+		if (!IS_ERR(p)) {
+			s = mangle_path(s, p, esc);
+			if (s) {
+				p = m->buf + m->count;
+				m->count = s - m->buf;
+				return s - p;
+			}
+		}
+	}
+	m->count = m->size;
+	return p == ERR_PTR(-ENAMETOOLONG) ? 0 : -1;
+}
+
+EXPORT_SYMBOL(seq_dentry);
+
 static void *single_start(struct seq_file *p, loff_t *pos)
 {
 	return NULL + (*pos == 0);
Index: linux-2.6.21.5/include/linux/dcache.h
===================================================================
--- linux-2.6.21.5.orig/include/linux/dcache.h
+++ linux-2.6.21.5/include/linux/dcache.h
@@ -294,6 +294,8 @@ extern struct dentry * d_hash_and_lookup
 extern int d_validate(struct dentry *, struct dentry *);

 extern char * d_path(struct dentry *, struct vfsmount *, char *, int);
+extern char * dentry_path(struct dentry *, char *, int);
+
   
 /* Allocation counts.. */

Index: linux-2.6.21.5/include/linux/seq_file.h
===================================================================
--- linux-2.6.21.5.orig/include/linux/seq_file.h
+++ linux-2.6.21.5/include/linux/seq_file.h
@@ -43,6 +43,7 @@ int seq_printf(struct seq_file *, const 
 	__attribute__ ((format (printf,2,3)));

 int seq_path(struct seq_file *, struct vfsmount *, struct dentry *,
char *);
+int seq_dentry(struct seq_file *, struct dentry *, char *);

 int single_open(struct file *, int (*)(struct seq_file *, void *), void
*);
 int single_release(struct inode *, struct file *);
Index: linux-2.6.21.5/fs/pnode.c
===================================================================
--- linux-2.6.21.5.orig/fs/pnode.c
+++ linux-2.6.21.5/fs/pnode.c
@@ -27,6 +27,28 @@ static inline struct vfsmount *next_slav
 	return list_entry(p->mnt_slave.next, struct vfsmount, mnt_slave);
 }

+/* return a peer in the same namespace */
+struct vfsmount *get_peer_same_ns(struct vfsmount *mnt)
+{
+	struct vfsmount *m = mnt;
+	do {
+		m = next_peer(m);
+	} while (mnt->mnt_ns != m->mnt_ns);
+	return m;
+}
+
+/* return a peer in the same namespace */
+struct vfsmount *get_master_same_ns(struct vfsmount *mnt)
+{
+	struct vfsmount *m = mnt->mnt_master;
+	struct vfsmount *tmp = m;
+	if (!m) return m;
+	do {
+		m = next_peer(m);
+	} while (tmp != m && mnt->mnt_ns != m->mnt_ns);
+	return m;
+}
+
 static int do_make_slave(struct vfsmount *mnt)
 {
 	struct vfsmount *peer_mnt = mnt, *master = mnt->mnt_master;
Index: linux-2.6.21.5/fs/pnode.h
===================================================================
--- linux-2.6.21.5.orig/fs/pnode.h
+++ linux-2.6.21.5/fs/pnode.h
@@ -34,4 +34,6 @@ int propagate_mnt(struct vfsmount *, str
 		struct list_head *);
 int propagate_umount(struct list_head *);
 int propagate_mount_busy(struct vfsmount *, int);
+struct vfsmount *get_master_same_ns(struct vfsmount *);
+struct vfsmount *get_peer_same_ns(struct vfsmount *);
 #endif /* _LINUX_PNODE_H */

Re: [RFC PATCH 1/1] VFS: Augment /proc/mount with subroot and shared-subtree

[Karel Zak]

On Mon, Jun 25, 2007 at 03:00:15PM -0700, Ram Pai wrote:
> Please check if the following modified patch meets the requirements.
> 
> It augments /proc/mount with additional information to
> 	(1) disambiguate bind mounts with subroot information.
> 	(2) display shared-subtree information using which one can
> 		determine the propagation trees.
> 
> 
> The following additional fields are appended to each record
> in /proc/mounts

 Can you append the new fields at real end of records? Now you have
 the new fields between "options" and "freq, passno".

 (BTW, maybe we can completely remove "freq, passno" from
 /proc/mounts, especially if we don't have care about compatibility
 with /etc/{mtab,fstab} format. The freq and passno are always zero in
 /proc/mounts).

> mntid=id    ->  The unique id associated with that mount.
> fsid=id:dir ->  The filesystem's id and directory in that filesystem
> that
> 		makes the root directory of this mount.
> parent=id   ->  The id of the mount's parent; on which it is mounted.

 Do we really need a "<name>=" (mntid=, fsid=, parent=) prefixes? I
 think your new fields are always in the same column (on same
 position).

> also flags are augmented with new information to indicate the mount's 
> propagation type.
> 
> Here is a sample 'cat /proc/mounts' after executing the following
> commands:
> mount --bind /mnt /mnt
> mount --make-shared /mnt
> mount --bind /mnt/1 /var
> mount --make-slave /var
> mount --make-shared /mnt
> mount --make-unbindable /proc
> 
> rootfs / rootfs rw PRIVATE mntid=c1708c30 fsid=1:/ parent=c1708c30 0 0
> /dev/root / ext2 rw  PRIVATE mntid=c1208c08 fsid=6200:/ parent=c1708c30
> 0 0
> /proc /proc proc rw UNBINDABLE mntid=c1108c90 fsid=3:/ parent=c1208c08 0
> 0
> devpts /dev/pts devpts rw PRIVATE mntid=c1108c18 fsid=a:/
> parent=c1208c08 0 0
> /dev/root /mnt ext2 rw  SHARED:peer=c1e08cb0 mntid=c1e08cb0
> fsid=6200:/mnt parent=c1208c08 0 0
> /dev/root /var ext2 rw  SHARED:peer=c1f08c28 SLAVE:master=c1e08cb0
> mntid=c1f08c28 fsid=6200:/mnt/1 parent=c1208c08 0 0

 You needn't "peer" or "master" keywords and it would be nice
 to use one column for all propagation flags (separated by comma).

    <FLAG>[:id>][,...]

 for example:

   SHARED:c1f08c28,SLAVE:c1e08cb0

 Full example:

 <fsname> <dir> <type> <opts> <freq> <passno> \
           <propflags> <mntid> <fsid> <parentid>

 rootfs / rootfs rw  0 0 PRIVATE c1708c30 1:/ c1708c30
 /dev/root / ext2 rw 0 0 PRIVATE 1208c08 6200:/ c1708c30
 /proc /proc proc rw  0 0 UNBINDABLE c1108c90 3:/ c1208c08
 devpts /dev/pts devpts rw  0 0 PRIVATE c1108c18 a:/ c1208c08
 /dev/root /mnt ext2 rw 0 0 SHARED:c1e08cb0 c1e08cb0 6200:/mnt c1208c08
 /dev/root /var ext2 rw 0 0 SHARED:c1f08c28,SLAVE:c1e08cb0 c1f08c28 6200:/mnt/1 c1208c08

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: [RFC PATCH 1/1] VFS: Augment /proc/mount with subroot and shared-subtree

[H. Peter Anvin]

Karel Zak wrote:
> 
>  (BTW, maybe we can completely remove "freq, passno" from
>  /proc/mounts, especially if we don't have care about compatibility
>  with /etc/{mtab,fstab} format. The freq and passno are always zero in
>  /proc/mounts).
> 

But we do, since there are applications which use getmntent() and 
friends to parse /proc/mounts.

	-hpa

Re: [RFC PATCH 1/1] VFS: Augment /proc/mount with subroot and shared-subtree

[Christoph Hellwig]

On Mon, Jun 25, 2007 at 03:00:15PM -0700, Ram Pai wrote:
> Please check if the following modified patch meets the requirements.
> 
> It augments /proc/mount with additional information to
> 	(1) disambiguate bind mounts with subroot information.
> 	(2) display shared-subtree information using which one can
> 		determine the propagation trees.
> 
> 
> The following additional fields are appended to each record
> in /proc/mounts

NACK.  Adding anything to the format will confuse the hell out of
existing parsers.  We really want something like your /proc/<pid>/mounts_new,
except mounts_new should have a better name (/proc/<pid>/ns anyone? :))

Re: [RFC PATCH 1/1] VFS: Augment /proc/mount with subroot and shared-subtree

[H. Peter Anvin]

Christoph Hellwig wrote:
>>
>> The following additional fields are appended to each record
>> in /proc/mounts
> 
> NACK.  Adding anything to the format will confuse the hell out of
> existing parsers.  We really want something like your /proc/<pid>/mounts_new,
> except mounts_new should have a better name (/proc/<pid>/ns anyone? :))
> 

Is that conjecture, or do you have evidence to that effect?  Most users 
of this file are using it via the glibc interfaces, and there probably 
aren't all that many users of it in the first place.

This was debated in some detail earlier in this thread.

(Note: this patch is still wrong, since it appends the new fields in the 
wrong place.)

	-hpa

Re: [RFC PATCH 1/1] VFS: Augment /proc/mount with subroot and shared-subtree

[Christoph Hellwig]

On Sat, Jun 30, 2007 at 08:56:02AM -0400, H. Peter Anvin wrote:
> Is that conjecture, or do you have evidence to that effect?  Most users 
> of this file are using it via the glibc interfaces, and there probably 
> aren't all that many users of it in the first place.

I have written parsers for personal projects that might not have been
happy to deal with additional fields myself for example..

Re: [RFC PATCH 1/1] VFS: Augment /proc/mount with subroot and shared-subtree

[Ram Pai]

On Wed, 2007-07-11 at 11:24 +0100, Christoph Hellwig wrote:
> On Sat, Jun 30, 2007 at 08:56:02AM -0400, H. Peter Anvin wrote:
> > Is that conjecture, or do you have evidence to that effect?  Most users 
> > of this file are using it via the glibc interfaces, and there probably 
> > aren't all that many users of it in the first place.
> 
> I have written parsers for personal projects that might not have been
> happy to deal with additional fields myself for example..

I modified the patch to add fields towards the end of each line.
i.e after 'freq, passno' fields. And symlinked /etc/mtab
to /proc/mounts.
mount,df  and friends were all perfectly happy.  

I imagine your script may also be happy with the additional fields
**towards the end**. I would like to avoid one more mount interface if
we can help it.

RP

[RFC2 PATCH 1/1] VFS: Augment /proc/mount with subroot and shared-subtree

[Ram Pai]

/proc/mounts in its current state fail to disambiguate bind mounts, especially 
when the bind mount is subrooted. Also it does not capture propagation state of
the mounts(shared-subtree). The following patch addresses the problem.

The following additional fields to /proc/mounts are added.

propagation-type in the form of <propagation_flag>[:<mntid>][,...]
	note: 'shared' flag is followed by the mntid of its peer mount
	      'slave' flag is followed by the mntid of its master mount
	      'private' flag stands by itself
	      'unbindable' flag stands by itself
   
mntid -- is a unique identifier of the mount
major:minor -- is the major minor number of the device hosting the filesystem
dir -- the subdir in the filesystem which forms the root of this mount
parent -- the id of the parent mount


Here is a sample cat /proc/mounts after execution the following commands:

mount --bind /mnt /mnt
mount --make-shared /mnt
mount --bind /mnt/1 /var
mount --make-slave /var
mount --make-shared /var
mount --bind /var/abc /tmp
mount --make-unbindable /proc

rootfs / rootfs rw 0 0 private 2 0:1 / 2 
/dev/root / ext2 rw  0 0 private 16 98:0 / 2 
/proc /proc proc rw 0 0 unbindable 17 0:3 / 16 
devpts /dev/pts devpts rw 0 0 private 18 0:10 / 16 
/dev/root /mnt ext2 rw  0 0 shared:19 19 98:0 /mnt 16 
/dev/root /var ext2 rw  0 0 shared:21,slave:19 20 98:0 /mnt/1 16 
/dev/root /tmp ext2 rw  0 0 shared:20,slave:19 21 98:0 /mnt/1/abc 16 

For example, the last line indicates that :

1) The mount is a shared mount.
2) Its peer mount of mount with id 20
3) It is also a slave mount of the master-mount with the id  19
4) The filesystem on device with major/minor number 98:0 and subdirectory 
	mnt/1/abc makes the root directory of this mount.
5) And finally the mount with id 16 is its parent.


Testing: symlinked /etc/mtab to /proc/mounts and did some mount and df commands. They worked normally.



Signed-off-by: Ram Pai <linuxram@us.ibm.com>

---
 fs/dcache.c              |   53 +++++++++++++++++++++++++++++++
 fs/namespace.c           |   35 +++++++++++++++++++-
 fs/pnode.c               |   22 +++++++++++++
 fs/pnode.h               |    2 +
 fs/seq_file.c            |   79 ++++++++++++++++++++++++++++++++++-------------
 include/linux/dcache.h   |    2 +
 include/linux/mount.h    |    1 
 include/linux/seq_file.h |    1 
 8 files changed, 172 insertions(+), 23 deletions(-)

Index: linux-2.6.21.5/fs/dcache.c
===================================================================
--- linux-2.6.21.5.orig/fs/dcache.c
+++ linux-2.6.21.5/fs/dcache.c
@@ -1835,6 +1835,59 @@ char * d_path(struct dentry *dentry, str
 	return res;
 }
 
+static inline int prepend(char **buffer, int *buflen, const char *str,
+					int namelen)
+{
+	if ((*buflen -= namelen) < 0)
+		return 1;
+	*buffer -= namelen;
+	memcpy(*buffer, str, namelen);
+	return 0;
+}
+
+/*
+ * write full pathname into buffer and return start of pathname.
+ * If @vfsmnt is not specified return the path relative to the
+ * its filesystem's root.
+ */
+char * dentry_path(struct dentry *dentry, char *buf, int buflen)
+{
+	char * end = buf+buflen;
+	char * retval;
+
+	spin_lock(&dcache_lock);
+	prepend(&end, &buflen, "\0", 1);
+	if (!IS_ROOT(dentry) && d_unhashed(dentry)) {
+		if (prepend(&end, &buflen, "//deleted", 10))
+			goto Elong;
+	}
+	/* Get '/' right */
+	retval = end-1;
+	*retval = '/';
+
+	for (;;) {
+		struct dentry * parent;
+		if (IS_ROOT(dentry))
+			break;
+
+		parent = dentry->d_parent;
+		prefetch(parent);
+
+		if (prepend(&end, &buflen, dentry->d_name.name,
+				dentry->d_name.len) ||
+	            prepend(&end, &buflen, "/", 1))
+			goto Elong;
+
+		retval = end;
+		dentry = parent;
+	}
+	spin_unlock(&dcache_lock);
+	return retval;
+Elong:
+	spin_unlock(&dcache_lock);
+	return ERR_PTR(-ENAMETOOLONG);
+}
+
 /*
  * NOTE! The user-level library version returns a
  * character pointer. The kernel system call just
Index: linux-2.6.21.5/fs/namespace.c
===================================================================
--- linux-2.6.21.5.orig/fs/namespace.c
+++ linux-2.6.21.5/fs/namespace.c
@@ -33,6 +33,8 @@
 __cacheline_aligned_in_smp DEFINE_SPINLOCK(vfsmount_lock);
 
 static int event;
+static atomic_t mnt_counter;
+
 
 static struct list_head *mount_hashtable __read_mostly;
 static int hash_mask __read_mostly, hash_bits __read_mostly;
@@ -51,6 +53,7 @@ static inline unsigned long hash(struct 
 	return tmp & hash_mask;
 }
 
+
 struct vfsmount *alloc_vfsmnt(const char *name)
 {
 	struct vfsmount *mnt = kmem_cache_zalloc(mnt_cache, GFP_KERNEL);
@@ -64,6 +67,7 @@ struct vfsmount *alloc_vfsmnt(const char
 		INIT_LIST_HEAD(&mnt->mnt_share);
 		INIT_LIST_HEAD(&mnt->mnt_slave_list);
 		INIT_LIST_HEAD(&mnt->mnt_slave);
+		mnt->mnt_id = atomic_inc_return(&mnt_counter);
 		if (name) {
 			int size = strlen(name) + 1;
 			char *newname = kmalloc(size, GFP_KERNEL);
@@ -386,9 +390,35 @@ static int show_vfsmnt(struct seq_file *
 		if (mnt->mnt_flags & fs_infop->flag)
 			seq_puts(m, fs_infop->str);
 	}
-	if (mnt->mnt_sb->s_op->show_options)
+	seq_putc(m, ' ');
+	if (mnt->mnt_sb->s_op->show_options) {
 		err = mnt->mnt_sb->s_op->show_options(m, mnt);
-	seq_puts(m, " 0 0\n");
+		seq_putc(m, ' ');
+	}
+	seq_puts(m, "0 0 ");
+	if (IS_MNT_SHARED(mnt)) {
+		seq_printf(m, "shared:%lu",
+				get_peer_same_ns(mnt)->mnt_id);
+		if (IS_MNT_SLAVE(mnt)) {
+			seq_printf(m, ",slave:%lu ",
+				get_master_same_ns(mnt)->mnt_id);
+		} else {
+			seq_putc(m, ' ');
+		}
+	} else if (IS_MNT_SLAVE(mnt)) {
+		seq_printf(m, "slave:%lu ",
+			get_master_same_ns(mnt)->mnt_id);
+	} else if (IS_MNT_UNBINDABLE(mnt)) {
+		seq_printf(m, "unbindable ");
+	} else {
+		seq_printf(m, "private ");
+	}
+	seq_printf(m, "%lu %u:%u ", mnt->mnt_id,
+				MAJOR(mnt->mnt_sb->s_dev),
+				MINOR(mnt->mnt_sb->s_dev));
+	seq_dentry(m, mnt->mnt_root, " \t\n\\");
+	seq_putc(m, ' ');
+	seq_printf(m, "%lu \n", mnt->mnt_parent->mnt_id);
 	return err;
 }
 
@@ -1822,6 +1852,7 @@ void __init mnt_init(unsigned long mempa
 	if (!mount_hashtable)
 		panic("Failed to allocate mount hash table\n");
 
+	atomic_set(&mnt_counter, 0);
 	/*
 	 * Find the power-of-two list-heads that can fit into the allocation..
 	 * We don't guarantee that "sizeof(struct list_head)" is necessarily
Index: linux-2.6.21.5/fs/seq_file.c
===================================================================
--- linux-2.6.21.5.orig/fs/seq_file.c
+++ linux-2.6.21.5/fs/seq_file.c
@@ -338,38 +338,75 @@ int seq_printf(struct seq_file *m, const
 }
 EXPORT_SYMBOL(seq_printf);
 
-int seq_path(struct seq_file *m,
-	     struct vfsmount *mnt, struct dentry *dentry,
-	     char *esc)
+static inline char *mangle_path(char *s, char *p, char *esc)
 {
+	while (s <= p) {
+		char c = *p++;
+		if (!c) {
+			return s;
+		} else if (!strchr(esc, c)) {
+			*s++ = c;
+		} else if (s + 4 > p) {
+			break;
+		} else {
+			*s++ = '\\';
+			*s++ = '0' + ((c & 0300) >> 6);
+			*s++ = '0' + ((c & 070) >> 3);
+			*s++ = '0' + (c & 07);
+		}
+	}
+	return NULL;
+}
+
+/*
+ * return the absolute path of 'dentry' residing in mount 'mnt'.
+ */
+int seq_path(struct seq_file *m, struct vfsmount *mnt, struct dentry *dentry,
+ 	     char *esc)
+{
+	char *p = NULL;
 	if (m->count < m->size) {
 		char *s = m->buf + m->count;
-		char *p = d_path(dentry, mnt, s, m->size - m->count);
+		p = d_path(dentry, mnt, s, m->size - m->count);
 		if (!IS_ERR(p)) {
-			while (s <= p) {
-				char c = *p++;
-				if (!c) {
-					p = m->buf + m->count;
-					m->count = s - m->buf;
-					return s - p;
-				} else if (!strchr(esc, c)) {
-					*s++ = c;
-				} else if (s + 4 > p) {
-					break;
-				} else {
-					*s++ = '\\';
-					*s++ = '0' + ((c & 0300) >> 6);
-					*s++ = '0' + ((c & 070) >> 3);
-					*s++ = '0' + (c & 07);
-				}
+			s = mangle_path(s, p, esc);
+			if (s) {
+				p = m->buf + m->count;
+				m->count = s - m->buf;
+				return s - p;
 			}
 		}
 	}
 	m->count = m->size;
-	return -1;
+	return p == ERR_PTR(-ENAMETOOLONG) ? 0 : -1;
 }
+
 EXPORT_SYMBOL(seq_path);
 
+/*
+ * returns the path of the 'dentry' from the root of its filesystem.
+ */
+int seq_dentry(struct seq_file *m, struct dentry *dentry, char *esc)
+{
+	char *p = NULL;
+	if (m->count < m->size) {
+		char *s = m->buf + m->count;
+		p = dentry_path(dentry, s, m->size - m->count);
+		if (!IS_ERR(p)) {
+			s = mangle_path(s, p, esc);
+			if (s) {
+				p = m->buf + m->count;
+				m->count = s - m->buf;
+				return s - p;
+			}
+		}
+	}
+	m->count = m->size;
+	return p == ERR_PTR(-ENAMETOOLONG) ? 0 : -1;
+}
+
+EXPORT_SYMBOL(seq_dentry);
+
 static void *single_start(struct seq_file *p, loff_t *pos)
 {
 	return NULL + (*pos == 0);
Index: linux-2.6.21.5/include/linux/dcache.h
===================================================================
--- linux-2.6.21.5.orig/include/linux/dcache.h
+++ linux-2.6.21.5/include/linux/dcache.h
@@ -294,6 +294,8 @@ extern struct dentry * d_hash_and_lookup
 extern int d_validate(struct dentry *, struct dentry *);
 
 extern char * d_path(struct dentry *, struct vfsmount *, char *, int);
+extern char * dentry_path(struct dentry *, char *, int);
+
   
 /* Allocation counts.. */
 
Index: linux-2.6.21.5/include/linux/seq_file.h
===================================================================
--- linux-2.6.21.5.orig/include/linux/seq_file.h
+++ linux-2.6.21.5/include/linux/seq_file.h
@@ -43,6 +43,7 @@ int seq_printf(struct seq_file *, const 
 	__attribute__ ((format (printf,2,3)));
 
 int seq_path(struct seq_file *, struct vfsmount *, struct dentry *, char *);
+int seq_dentry(struct seq_file *, struct dentry *, char *);
 
 int single_open(struct file *, int (*)(struct seq_file *, void *), void *);
 int single_release(struct inode *, struct file *);
Index: linux-2.6.21.5/fs/pnode.c
===================================================================
--- linux-2.6.21.5.orig/fs/pnode.c
+++ linux-2.6.21.5/fs/pnode.c
@@ -27,6 +27,28 @@ static inline struct vfsmount *next_slav
 	return list_entry(p->mnt_slave.next, struct vfsmount, mnt_slave);
 }
 
+/* return a peer in the same namespace */
+struct vfsmount *get_peer_same_ns(struct vfsmount *mnt)
+{
+	struct vfsmount *m = mnt;
+	do {
+		m = next_peer(m);
+	} while (mnt->mnt_ns != m->mnt_ns);
+	return m;
+}
+
+/* return a peer in the same namespace */
+struct vfsmount *get_master_same_ns(struct vfsmount *mnt)
+{
+	struct vfsmount *m = mnt->mnt_master;
+	struct vfsmount *tmp = m;
+	if (!m) return m;
+	do {
+		m = next_peer(m);
+	} while (tmp != m && mnt->mnt_ns != m->mnt_ns);
+	return m;
+}
+
 static int do_make_slave(struct vfsmount *mnt)
 {
 	struct vfsmount *peer_mnt = mnt, *master = mnt->mnt_master;
Index: linux-2.6.21.5/fs/pnode.h
===================================================================
--- linux-2.6.21.5.orig/fs/pnode.h
+++ linux-2.6.21.5/fs/pnode.h
@@ -34,4 +34,6 @@ int propagate_mnt(struct vfsmount *, str
 		struct list_head *);
 int propagate_umount(struct list_head *);
 int propagate_mount_busy(struct vfsmount *, int);
+struct vfsmount *get_master_same_ns(struct vfsmount *);
+struct vfsmount *get_peer_same_ns(struct vfsmount *);
 #endif /* _LINUX_PNODE_H */
Index: linux-2.6.21.5/include/linux/mount.h
===================================================================
--- linux-2.6.21.5.orig/include/linux/mount.h
+++ linux-2.6.21.5/include/linux/mount.h
@@ -53,6 +53,7 @@ struct vfsmount {
 	struct list_head mnt_slave;	/* slave list entry */
 	struct vfsmount *mnt_master;	/* slave is on master->mnt_slave_list */
 	struct mnt_namespace *mnt_ns;	/* containing namespace */
+	unsigned long   mnt_id;		/* mount identifier */
 	/*
 	 * We put mnt_count & mnt_expiry_mark at the end of struct vfsmount
 	 * to let these frequently modified fields in a separate cache line

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Karel Zak]

On Wed, Jun 20, 2007 at 10:03:43PM +0100, Al Viro wrote:
> On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
> > ... 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
> 
> Hell, no.  The first field is in principle impossible to parse unless
> you know the fs type.
> 
> How about making a new file with sane format?  From the very
> beginning.  E.g. mountpoint + ID + relative path + type + options,
> where ID uniquely identifies superblock (e.g. numeric st_dev)
> and backing device (if any) is sitting among the options...

 Yeah. How about include propagation trees to this file?

 mountpoint + ID + relative path + type + options + propagation-flag +
 {peer,master}-mount-id

 / 0xa917800 / ext3 rw PRIVATE
 /mnt 0xa917100 / ext3 rw SHARED peer:0xa917100
 /tmp 0xa917f00 /1 ext3 rw SLAVE master:0xa917100



    Karel


-- 
 Karel Zak  <kzak@redhat.com>

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Karel Zak wrote:
> 
>  Yeah. How about include propagation trees to this file?
> 
>  mountpoint + ID + relative path + type + options + propagation-flag +
>  {peer,master}-mount-id
> 
>  / 0xa917800 / ext3 rw PRIVATE
>  /mnt 0xa917100 / ext3 rw SHARED peer:0xa917100
>  /tmp 0xa917f00 /1 ext3 rw SLAVE master:0xa917100
> 

I think we're talking about a different meaning of "id" here... you seem
to be talking about the vfsmount pointer, whereas it was originally
proposed as mnt_sb->sb_dev.  Both are useful, for different reasons of
course.

We should include mnt_devname as well.

People are a bit nervous about exposing kernel pointers in userspace, I
have noticed; would it be better to add a "mnt_id" field to struct
vfsmount; this can simply be a counter assigned when the structure is
assigned and then never changed (it might have to be a 64-bit counter,
but I don't think that adding 8 bytes to struct vfsmount should be a
huge deal.)

Does that service everyone's needs?

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Chuck Lever]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Al Viro wrote:
> On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
>> ... 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
> 
> Hell, no.  The first field is in principle impossible to parse unless
> you know the fs type.
> 
> How about making a new file with sane format?  From the very
> beginning.  E.g. mountpoint + ID + relative path + type + options,
> where ID uniquely identifies superblock (e.g. numeric st_dev)
> and backing device (if any) is sitting among the options...

To support NFS client performance statistics, I recently added 
/proc/self/mountstats.  That might be a place to add details about 
--move and --bind mounts without changing the format of /proc/mounts.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 291 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel/
version:2.1
end:vcard

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Chuck Lever wrote:
> To support NFS client performance statistics, I recently added
> /proc/self/mountstats.  That might be a place to add details about
> --move and --bind mounts without changing the format of /proc/mounts.

I just looked at /proc/self/mountstats; it seems to have no more
information than /proc/self/mounts, but in an even more annoying format.
 Either I'm missing something, this file doesn't add anything at all.

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Chuck Lever]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

H. Peter Anvin wrote:
> Chuck Lever wrote:
>> To support NFS client performance statistics, I recently added
>> /proc/self/mountstats.  That might be a place to add details about
>> --move and --bind mounts without changing the format of /proc/mounts.
> 
> I just looked at /proc/self/mountstats; it seems to have no more
> information than /proc/self/mounts, but in an even more annoying format.
>  Either I'm missing something, this file doesn't add anything at all.

The advantage is that it doesn't have strong user space dependencies on 
its format like /proc/mounts does.

If you have NFS mount points, you will see that it includes a great deal 
of additional information about each mount.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 291 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel/
version:2.1
end:vcard

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Chuck Lever wrote:
> The advantage is that it doesn't have strong user space dependencies on
> its format like /proc/mounts does.
> 
> If you have NFS mount points, you will see that it includes a great deal
> of additional information about each mount.

OK, I see now:
device raidtest:/export mounted on /net/raidtest/export with fstype nfs
statvers=1.0
        opts:
rw,vers=3,rsize=131072,wsize=131072,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys
        age:    5
        caps:   caps=0x9,wtmult=4096,dtsize=4096,bsize=0,namelen=255
        sec:    flavor=1,pseudoflavor=1
        events: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
        bytes:  0 0 0 0 0 0 0 0
        RPC iostats version: 1.0  p/v: 100003/3 (nfs)
        xprt:   tcp 686 0 2 0 5 8 8 0 8 0
        per-op statistics
                NULL: 0 0 0 0 0 0 0 0
             GETATTR: 2 2 0 264 224 1 0 1
             SETATTR: 0 0 0 0 0 0 0 0
              LOOKUP: 0 0 0 0 0 0 0 0
              ACCESS: 1 1 0 116 120 0 0 0
            READLINK: 0 0 0 0 0 0 0 0
                READ: 0 0 0 0 0 0 0 0
               WRITE: 0 0 0 0 0 0 0 0
              CREATE: 0 0 0 0 0 0 0 0
               MKDIR: 0 0 0 0 0 0 0 0
             SYMLINK: 0 0 0 0 0 0 0 0
               MKNOD: 0 0 0 0 0 0 0 0
              REMOVE: 0 0 0 0 0 0 0 0
               RMDIR: 0 0 0 0 0 0 0 0
              RENAME: 0 0 0 0 0 0 0 0
                LINK: 0 0 0 0 0 0 0 0
             READDIR: 0 0 0 0 0 0 0 0
         READDIRPLUS: 0 0 0 0 0 0 0 0
              FSSTAT: 1 1 0 132 84 0 1 1
              FSINFO: 1 1 0 132 80 0 0 0
            PATHCONF: 0 0 0 0 0 0 0 0
              COMMIT: 0 0 0 0 0 0 0 0

This format is just awful for parsing.  It's pretty clearly totally
ad-hoc.  It's not even self-consistent (it uses different separators,
etc, in the same file!)  It's reasonably compact for human consumption,
but it doesn't show what the arrays mean.

Heck, XML would have been better than this mess...

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Chuck Lever]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

H. Peter Anvin wrote:
> Chuck Lever wrote:
>> The advantage is that it doesn't have strong user space dependencies on
>> its format like /proc/mounts does.
>>
>> If you have NFS mount points, you will see that it includes a great deal
>> of additional information about each mount.
> 
> OK, I see now:
> device raidtest:/export mounted on /net/raidtest/export with fstype nfs
> statvers=1.0
>         opts:
> rw,vers=3,rsize=131072,wsize=131072,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys
>         age:    5
>         caps:   caps=0x9,wtmult=4096,dtsize=4096,bsize=0,namelen=255
>         sec:    flavor=1,pseudoflavor=1
>         events: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>         bytes:  0 0 0 0 0 0 0 0
>         RPC iostats version: 1.0  p/v: 100003/3 (nfs)
>         xprt:   tcp 686 0 2 0 5 8 8 0 8 0
>         per-op statistics
>                 NULL: 0 0 0 0 0 0 0 0
>              GETATTR: 2 2 0 264 224 1 0 1
>              SETATTR: 0 0 0 0 0 0 0 0
>               LOOKUP: 0 0 0 0 0 0 0 0
>               ACCESS: 1 1 0 116 120 0 0 0
>             READLINK: 0 0 0 0 0 0 0 0
>                 READ: 0 0 0 0 0 0 0 0
>                WRITE: 0 0 0 0 0 0 0 0
>               CREATE: 0 0 0 0 0 0 0 0
>                MKDIR: 0 0 0 0 0 0 0 0
>              SYMLINK: 0 0 0 0 0 0 0 0
>                MKNOD: 0 0 0 0 0 0 0 0
>               REMOVE: 0 0 0 0 0 0 0 0
>                RMDIR: 0 0 0 0 0 0 0 0
>               RENAME: 0 0 0 0 0 0 0 0
>                 LINK: 0 0 0 0 0 0 0 0
>              READDIR: 0 0 0 0 0 0 0 0
>          READDIRPLUS: 0 0 0 0 0 0 0 0
>               FSSTAT: 1 1 0 132 84 0 1 1
>               FSINFO: 1 1 0 132 80 0 0 0
>             PATHCONF: 0 0 0 0 0 0 0 0
>               COMMIT: 0 0 0 0 0 0 0 0
> 
> This format is just awful for parsing.  It's pretty clearly totally
> ad-hoc.  It's not even self-consistent (it uses different separators,
> etc, in the same file!)  It's reasonably compact for human consumption,
> but it doesn't show what the arrays mean.
> 
> Heck, XML would have been better than this mess...

Sigh.  So where where you when I asked for review time and again?

I have a couple of simple Python scripts that can parse this without any 
difficulty.

I resent your tone.  Quite a bit.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 291 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel/
version:2.1
end:vcard

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Al Viro wrote:
> On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
>> ... 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
> 
> Hell, no.  The first field is in principle impossible to parse unless
> you know the fs type.
> 
> How about making a new file with sane format?  From the very
> beginning.  E.g. mountpoint + ID + relative path + type + options,
> where ID uniquely identifies superblock (e.g. numeric st_dev)
> and backing device (if any) is sitting among the options...

The more I'm thinking about this, I think it's simplest to just add
fields to the right of the existing /proc/*/mounts.  Yes, the format is
ugly, and it will end up being uglier still, but it's also ugly to have
a bunch of different chunks of information formatted in different ways.

So, the existing fields are:

mnt_devname mnt_path filesystem_type options 0 0

... and we'd want to add ...

mnt_id propagation_info sb_dev path_to_fs_root

As previously stated, in order to avoid having to expose kernel
addresses to userspace, I suggest we simply add a counter field to
struct vfsmount and use that for mnt_id.

I'm not all that up on what is needed for propagation_info.  I presume
we want to be able to deduce the full mount lattice.  One particularly
important thing in my mind is to be able to distinguish overmounted
filesystems (which I think is possible in the current setup only by
ordering -- the filesystem on top I believe will end up last in
/proc/mounts, but I don't know if there actually is anything that
enforces that.)

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Serge E. Hallyn]

Quoting H. Peter Anvin (hpa@zytor.com):
> Al Viro wrote:
> > On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
> >> ... 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
> > 
> > Hell, no.  The first field is in principle impossible to parse unless
> > you know the fs type.
> > 
> > How about making a new file with sane format?  From the very
> > beginning.  E.g. mountpoint + ID + relative path + type + options,
> > where ID uniquely identifies superblock (e.g. numeric st_dev)
> > and backing device (if any) is sitting among the options...
> 
> The more I'm thinking about this, I think it's simplest to just add
> fields to the right of the existing /proc/*/mounts.  Yes, the format is
> ugly, and it will end up being uglier still, but it's also ugly to have
> a bunch of different chunks of information formatted in different ways.

Since we're defining the order "arbitrarily" in any case, I really don't
think it's all that ugly.

Are there any existing tools which would not be able to handle the extra
fields?

(suppose it's easiest to just add the fields, try a few distros, and see
which balk)

> So, the existing fields are:
> 
> mnt_devname mnt_path filesystem_type options 0 0
> 
> ... and we'd want to add ...
> 
> mnt_id propagation_info sb_dev path_to_fs_root
> 
> As previously stated, in order to avoid having to expose kernel
> addresses to userspace, I suggest we simply add a counter field to
> struct vfsmount and use that for mnt_id.

Agreed - even if it weren't frowned upon to expose the kernel addresses,
it would just be much nicer to have easier to remember ids.  Somehow
with the kernel address, even with just a set of 5 of them printed in
front of me it takes me 2 minutes to figure out which ones are the
same...

> I'm not all that up on what is needed for propagation_info.  I presume
> we want to be able to deduce the full mount lattice.  One particularly

I think Ram's existing patches just provided "PEER (next-peer-id)" or
"SLAVE (master-id)".

> important thing in my mind is to be able to distinguish overmounted
> filesystems (which I think is possible in the current setup only by

What exactly do you mean here?  Do you mean information about stackable
filesystems - i.e. ecryptfs, unionfs, etc?

If so, maybe a last column which the fs itself can fill in with such
information is the best way to go then?  Ecryptfs would have just one
pathname to fill in (the location of the encrypted dir), unionfs might
have several (the full stack of unioned directories).

> ordering -- the filesystem on top I believe will end up last in
> /proc/mounts, but I don't know if there actually is anything that
> enforces that.)

Hmm, or do you actually mean that if i'd done

	mount --bind /tmp/a /tmp
	mount --bind /tmp/b /tmp
	mount --bind /tmp/c /tmp

that you would want to see information about the first two mounts?

-serge

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Serge E. Hallyn wrote:
> 
> Hmm, or do you actually mean that if i'd done
> 
> 	mount --bind /tmp/a /tmp
> 	mount --bind /tmp/b /tmp
> 	mount --bind /tmp/c /tmp
> 
> that you would want to see information about the first two mounts?
> 

Yes.  Right now, you see all three without any reliable way of knowing
which one is on top.

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Pavel Machek]

Hi!

> > ... 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
> 
> Hell, no.  The first field is in principle impossible to parse unless
> you know the fs type.
> 
> How about making a new file with sane format?  From the very

Well, what about /sysfs, with its one value per file rule?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Pavel Machek wrote:
> Hi!
> 
>>> ... 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
>> Hell, no.  The first field is in principle impossible to parse unless
>> you know the fs type.
>>
>> How about making a new file with sane format?  From the very
> 
> Well, what about /sysfs, with its one value per file rule?
> 

There are two reasons not to do it that way:

- atomicity
- backwards compatibility

Of these, I would argue the former is the most important.

Additionally, I don't think sysfs has the ability to present different 
structures on a per-process basis; keep in mind this isn't really 
/proc/mounts, but really /proc/<pid>/mounts.

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Karel Zak]

On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
> 
> 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

 I prefer this format. It's compatible with the mount(8) -- the mount
 ignores extra columns.

> ... 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

 We needn't a new separator (':') there already is one (' ').

> 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.

 Many people use "ln -s /proc/mounts /etc/mtab".

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Karel Zak wrote:
> On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
>> 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
> 
>  I prefer this format. It's compatible with the mount(8) -- the mount
>  ignores extra columns.
> 
>> ... 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
> 
>  We needn't a new separator (':') there already is one (' ').
> 
>> 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.
> 
>  Many people use "ln -s /proc/mounts /etc/mtab".
> 

Out of curiosity, and trying to better grok the problem, what would
mount(8) do differently with the second format versus the first?

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Dr. David Alan Gilbert]

* Karel Zak (kzak@redhat.com) wrote:
> On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote:
> > 

<snip>

> > ... 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
> 
>  We needn't a new separator (':') there already is one (' ').

What happens with the (sick) case of spaces in directory names?
Also is it really nicely defined that there is no way to put a space
in an option in any of the filesystems?   I suppose someone
particularly sick could have a device node in a directory with a space
in it.  It would be nice if new formats for this are being defined
to make it cover everything.

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Dr. David Alan Gilbert wrote:
> 
> What happens with the (sick) case of spaces in directory names?
> Also is it really nicely defined that there is no way to put a space
> in an option in any of the filesystems?   I suppose someone
> particularly sick could have a device node in a directory with a space
> in it.  It would be nice if new formats for this are being defined
> to make it cover everything.
> 

That's already handled just fine:

bash-3.1$ mkdir /tmp/'Jag är: \
en liten mask'
bash-3.1$ sudo mount -t tmpfs none '/tmp/Jag är: \
en liten mask'/
bash-3.1$ tail -1 /proc/mounts
none /tmp/Jag\040är:\040\134\012en\040liten\040mask tmpfs rw 0 0
bash-3.1$

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Hans-Peter Jansen]

Am Donnerstag, 21. Juni 2007 00:46 schrieb H. Peter Anvin:
> Dr. David Alan Gilbert wrote:
> > What happens with the (sick) case of spaces in directory names?
> > Also is it really nicely defined that there is no way to put a space
> > in an option in any of the filesystems?   I suppose someone
> > particularly sick could have a device node in a directory with a space
> > in it.  It would be nice if new formats for this are being defined
> > to make it cover everything.
>
> That's already handled just fine:
>
> bash-3.1$ mkdir /tmp/'Jag är: \
> en liten mask'
> bash-3.1$ sudo mount -t tmpfs none '/tmp/Jag är: \
> en liten mask'/
> bash-3.1$ tail -1 /proc/mounts
> none /tmp/Jag\040är:\040\134\012en\040liten\040mask tmpfs rw 0 0
> bash-3.1$

Hmm, and what about the even sicker case: /tmp/\040, parse as /tmp/\\040?
Do userspace cope with this?

Happy parsingly y'rs,
  Pete

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[H. Peter Anvin]

Hans-Peter Jansen wrote:
>> That's already handled just fine:
>>
>> bash-3.1$ mkdir /tmp/'Jag är: \
>> en liten mask'
>> bash-3.1$ sudo mount -t tmpfs none '/tmp/Jag är: \
>> en liten mask'/
>> bash-3.1$ tail -1 /proc/mounts
>> none /tmp/Jag\040är:\040\134\012en\040liten\040mask tmpfs rw 0 0
>> bash-3.1$
> 
> Hmm, and what about the even sicker case: /tmp/\040, parse as /tmp/\\040?
> Do userspace cope with this?

Look at the example above, it contains a backslash already.  It's
escaped as \134.

"Does userspace cope with this" is of course an impossible question to
answer, since userspace is in theory unbounded.  However, if it doesn't,
it is broken and needs to be fixed.

	-hpa

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Nix]

On 20 Jun 2007, H. Peter Anvin verbalised:

> 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.

It's also highly desirable if you want to be able to run a backup :) one
would desire to back up the filesystem as a whole, not some bind mount
of one directory out of it (and backing up both is needless
duplication).

So I applaud this and would be an immediate user, no matter what format
is chosen, as long as we can tell what is mounted where.

(As an aside, it would be nice if mount(8) could supply (a limited
amount of) extra (arbitrary?) textual options to the kernelq,
specifically so that mount options which are only interpreted by
userspace programs, like `user' and the quota options, could appear in
/proc/mounts. That way we could finally ditch bloody /etc/mtab for good.

(Any other approach requires mount(8) to keep track of these options in
a separate file, which brings back exactly the same synchronization
horrors that we're all so nauseatingly familiar with from /etc/mtab.)

> 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.

Quite so. The output from df(8) in the presence of large numbers of bind
mounts was ludicrous before it started explicitly ignoring filesystems
of type `none', and that was arguably the wrong place to fix it.

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Miklos Szeredi]

> > 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.
> 
> It's also highly desirable if you want to be able to run a backup :) one
> would desire to back up the filesystem as a whole, not some bind mount
> of one directory out of it (and backing up both is needless
> duplication).
> 
> So I applaud this and would be an immediate user, no matter what format
> is chosen, as long as we can tell what is mounted where.
> 
> (As an aside, it would be nice if mount(8) could supply (a limited
> amount of) extra (arbitrary?) textual options to the kernelq,
> specifically so that mount options which are only interpreted by
> userspace programs, like `user' and the quota options, could appear in
> /proc/mounts. That way we could finally ditch bloody /etc/mtab for good.

I'm working on this actually.  See this (and related patches) in -mm:

  http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/broken-out/unprivileged-mounts-add-user-mounts-to-the-kernel.patch

This solves the "user=" thing, but is not a generic solution for other
options.  And I'm wondering if there is really a need for that.

Which quota options are you thinking about?  Some quota options
(e.g. for ext*) seem to be already present in /proc/mounts.

There's also "loop=", but that's not really a per-mount option, but a
per-loop-device option, so it could be stored separately under /var.

Do you know any other options which are only in /etc/mtab, and need to
be stored along with each mount?

Miklos

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

[Nix]

On 21 Jun 2007, Miklos Szeredi said:
> I'm working on this actually.  See this (and related patches) in -mm:
>
>   http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/broken-out/unprivileged-mounts-add-user-mounts-to-the-kernel.patch
>
> This solves the "user=" thing, but is not a generic solution for other
> options.  And I'm wondering if there is really a need for that.

I'm not sure there is, actually...

> Which quota options are you thinking about?  Some quota options
> (e.g. for ext*) seem to be already present in /proc/mounts.

... last I checked, usrquota and grpquota weren't being propagated in,
but that's changed sometime in the last, um, wow, has it been two
years already? Perhaps I should have checked again before babbling
nonsense to an audience of thousands, sorry!

> Do you know any other options which are only in /etc/mtab, and need to
> be stored along with each mount?

None presently, but in general it seems strange to have to modify the
kernel in order to be able to reliably associate some new key/value pair
with a mount point, let alone to have to do it on a filesystem-by-
filesystem basis...

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously