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
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
> 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?). 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
> > 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 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
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
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 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
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 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 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 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
> > 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//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, 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
