Re: [patch] VFS: extend /proc/mounts
The alternative (and completely safe) solution is to add another file to proc. Me no likey. Since we need saner layout, I would strongly suggest exactly that. I don't think there's all that much wrong with the current layout, except the two dummy zeroes at the end. Or, something else needs fixing in there? major:minor -- is the major minor number of the device hosting the filesystem Bad description. Value of st_dev for files on that filesystem, please - there might be no such thing as the device hosting the filesystem _and_ the value here may bloody well be unrelated to device actually holding all data (for things like ext2meta, etc.). Right. 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. I'd suggest doing a new file that would *not* try to imitate /etc/mtab. Another thing is, how much of propagation information do we want to be exposed and what do we intend to do with it? I think the scheme devised by Ram is basically right. It shows the relationships (slave, peer) and the ID of a master/peer mount. What I changed, is to always show a canonical peer, because I think that is more useful in establishing relationships between mounts. Is this info sensitive? I can't see why it would be. Note that entire propagation tree is out of question - it spans many namespaces and contains potentially sensitive information. So we won't see all nodes. With multiple namespaces, of course you are only allowed to see a part of the tree, but you could have xterms for all of them, and can put together the big picture from the pieces. What do we want to *do* with the information about propagation? Just feedback about the state of the thing. It's very annoying, that after setting up propagation, it's impossible to check the result. Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
On Thu, Jan 17, 2008 at 09:36:11AM +0100, Miklos Szeredi wrote: I'd suggest doing a new file that would *not* try to imitate /etc/mtab. Another thing is, how much of propagation information do we want to be exposed and what do we intend to do with it? I think the scheme devised by Ram is basically right. It shows the relationships (slave, peer) and the ID of a master/peer mount. Yes. It also shows the full relationship between source and destination for bind mounts. Now the /proc/mounts is useless: # mount --bind /mnt/test /mnt/test2 # cat /proc/mounts | grep test /dev/root /mnt/test2 ext3 rw,noatime,data=ordered 0 0 What do we want to *do* with the information about propagation? Just feedback about the state of the thing. It's very annoying, that after setting up propagation, it's impossible to check the result. Exactly. Karel -- Karel Zak [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
On Jan 17, 2008, at 3:55 AM, Miklos Szeredi wrote: Hey, I just found /proc/X/mountstats. How does this fit in to the big picture? It seems to show some counters for NFS mounts, no other filesystem uses it. Format looks rather less nice, than /proc/X/mounts (why do we need long english sentences under /proc?). I introduced /proc/self/mountstats because we need a way for non- block-device-based file systems to report I/O statistics. Everything else I tried was rejected, and apparently what we ended up with was reviewed by only a handful of people, so no one else likes it or uses it. It can go away for all I care, as long as we retain some flexible mechanism for non-block-based file systems to report I/O stats. As far as I am aware, there are only two user utilities that understand and parse this data, and I maintain both. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] VFS: extend /proc/mounts
The reason, why this patch was dug up, is that if the bdi-sysfs patch
is going to use device numbers to identify BDIs, then there should be
a way for the user to map the device number into mount(s).
But it's useful regardless of the bdi-sysfs patch.
Can this be added to -mm?
In theory it could break userspace, but I think it's very unlikely to
do so, because stuff is added only at the end of the lines, and
because most programs probably parse it through the libc interface
which is not broken by this change. Despite this, it should be tested
on as many systems as possible.
The alternative (and completely safe) solution is to add another file
to proc. Me no likey.
Miklos
From: Ram Pai [EMAIL PROTECTED]
/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.
[EMAIL PROTECTED]:
- for mount ID's use IRA instead of a 32bit counter, which could overflow
- print canonical ID's (smallest one within the peer group) for peers
and master, this is more useful, than a random ID within the same namespace
- fix a couple of small bugs
- style fixes
Signed-off-by: Ram Pai [EMAIL PROTECTED]
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
---
Index: linux/fs/dcache.c
===
--- linux.orig/fs/dcache.c 2008-01-09 21:16:28.0 +0100
+++ linux/fs/dcache.c 2008-01-16 20:26:56.0 +0100
@@ -1890,6 +1890,60 @@ char *dynamic_dname(struct dentry *dentr
return memcpy(buffer, temp, sz);
}
+static inline int prepend(char **buffer, int *buflen, const char *str,
+ int namelen)
+{
+ *buflen -= namelen;
+ if (*buflen 0)
+ return 1;
+ *buffer -= namelen;
+ memcpy(*buffer, str, namelen);
+ return 0;
+}
+
+/*
+ * Write full pathname from the root of the filesystem into the buffer.
+ */
+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, 9))
+ goto Elong;
+ }
+ if (buflen 1)
+ 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/fs/namespace.c
Re: [patch] VFS: extend /proc/mounts
On Wed, 16 Jan 2008 23:12:31 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote: The reason, why this patch was dug up, is that if the bdi-sysfs patch is going to use device numbers to identify BDIs, then there should be a way for the user to map the device number into mount(s). But it's useful regardless of the bdi-sysfs patch. Don't know what that is. Can this be added to -mm? In theory it could break userspace, but I think it's very unlikely to do so, because stuff is added only at the end of the lines, and because most programs probably parse it through the libc interface which is not broken by this change. Despite this, it should be tested on as many systems as possible. Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. - for mount ID's use IRA instead of a 32bit counter, which could overflow don't know what an IRA is. - print canonical ID's (smallest one within the peer group) for peers and master, this is more useful, than a random ID within the same namespace - fix a couple of small bugs - style fixes Signed-off-by: Ram Pai [EMAIL PROTECTED] Signed-off-by: Miklos Szeredi [EMAIL PROTECTED] Both the newly-added inlines in this patch are wrong. They will result in a larger and slower kernel. This should be very well known by now. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
The reason, why this patch was dug up, is that if the bdi-sysfs patch is going to use device numbers to identify BDIs, then there should be a way for the user to map the device number into mount(s). But it's useful regardless of the bdi-sysfs patch. Don't know what that is. Subject: mm: sysfs: expose the BDI object in sysfs Provide a place in sysfs for the backing_dev_info object. This allows us to see and set the various BDI specific variables. In particular this properly exposes the read-ahead window for all relevant users and /sys/block/block/queue/read_ahead_kb should be deprecated. Can this be added to -mm? In theory it could break userspace, but I think it's very unlikely to do so, because stuff is added only at the end of the lines, and because most programs probably parse it through the libc interface which is not broken by this change. Despite this, it should be tested on as many systems as possible. Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. Dunno. I feel, this is quite safe, because even the home-grown parsers will likely care about any junk at the end of the line. But of course this cannot be proved. - for mount ID's use IRA instead of a 32bit counter, which could overflow don't know what an IRA is. That was meant to be IDA (from the IDR library). - print canonical ID's (smallest one within the peer group) for peers and master, this is more useful, than a random ID within the same namespace - fix a couple of small bugs - style fixes Signed-off-by: Ram Pai [EMAIL PROTECTED] Signed-off-by: Miklos Szeredi [EMAIL PROTECTED] Both the newly-added inlines in this patch are wrong. They will result in a larger and slower kernel. This should be very well known by now. I'll get rid of them. Miklos - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
On Wed, Jan 16, 2008 at 02:30:51PM -0800, Andrew Morton wrote: On Wed, 16 Jan 2008 23:12:31 +0100 Miklos Szeredi [EMAIL PROTECTED] wrote: In theory it could break userspace, but I think it's very unlikely to do so, because stuff is added only at the end of the lines, and because most programs probably parse it through the libc interface which is not broken by this change. Despite this, it should be tested on as many systems as possible. Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. So, let's use /proc/mounts_v2 ;-) Karel -- Karel Zak [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
On Jan 17 2008 00:43, Karel Zak wrote: Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. So, let's use /proc/mounts_v2 ;-) Was not it like don't use /proc for new things? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt [EMAIL PROTECTED] wrote: On Jan 17 2008 00:43, Karel Zak wrote: Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. So, let's use /proc/mounts_v2 ;-) Was not it like don't use /proc for new things? Well yeah. If we're going to do a brand new mechanism to expose per-mount data then we should hunker down and get it right. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
On Thursday January 17, [EMAIL PROTECTED] wrote: On Jan 17 2008 00:43, Karel Zak wrote: Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. So, let's use /proc/mounts_v2 ;-) Was not it like don't use /proc for new things? I thought it was don't use /proc for new things that aren't process related. And as the mount table is per process.. A host has a bunch of mounted filesystems (struct super_block), and each process has some subset of these stitched together into a mount tree (struct vfsmount / struct namespace). There needs to be something in /proc that exposes the vfsmount tree. Arguably there should be something else - maybe in sysfs - that provides access to the struct superblock object. And there needs to be a clear way to relate information from one with information from the other. In the tradition of stat, statm, status, maybe the former should be /proc/$PID/mountm :-) Hey, I just found /proc/X/mountstats. How does this fit in to the big picture? NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
On Jan 17 2008 11:33, Neil Brown wrote: On Thursday January 17, [EMAIL PROTECTED] wrote: On Jan 17 2008 00:43, Karel Zak wrote: Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. So, let's use /proc/mounts_v2 ;-) Was not it like don't use /proc for new things? I thought it was don't use /proc for new things that aren't process related. And as the mount table is per process.. You are right. I'm still in the world where CLONE_NEWNS is not used all that much in the daily routine, either by the distro or by me. In the tradition of stat, statm, status, maybe the former should be /proc/$PID/mountm What next - /proc/pid/mountus? :) - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
Andrew Morton wrote: Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. There is a lot of precedent for adding fields at the end. Since the last fields in current /proc/*/mounts are dummy fields anyway, it doesn't matter if the homegrown parsers concatenate the additional information to those. -hpa - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
On Wed, Jan 16, 2008 at 11:12:31PM +0100, Miklos Szeredi wrote: The alternative (and completely safe) solution is to add another file to proc. Me no likey. Since we need saner layout, I would strongly suggest exactly that. major:minor -- is the major minor number of the device hosting the filesystem Bad description. Value of st_dev for files on that filesystem, please - there might be no such thing as the device hosting the filesystem _and_ the value here may bloody well be unrelated to device actually holding all data (for things like ext2meta, etc.). 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. I'd suggest doing a new file that would *not* try to imitate /etc/mtab. Another thing is, how much of propagation information do we want to be exposed and what do we intend to do with it? Note that entire propagation tree is out of question - it spans many namespaces and contains potentially sensitive information. So we won't see all nodes. What do we want to *do* with the information about propagation? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] VFS: extend /proc/mounts
On Wed, Jan 16, 2008 at 04:09:30PM -0800, Andrew Morton wrote: On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt [EMAIL PROTECTED] wrote: On Jan 17 2008 00:43, Karel Zak wrote: Seems like a plain bad idea to me. There will be any number of home-made /proc/mounts parsers and we don't know what they do. So, let's use /proc/mounts_v2 ;-) Was not it like don't use /proc for new things? Well yeah. If we're going to do a brand new mechanism to expose per-mount data then we should hunker down and get it right. Which automatically means no sysfs. We are NOT converting vfsmounts to kobject-based lifetime rules. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
