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