On Wed, 16 Jan 2008 23:12:31 +0100


Seems like a plain bad idea to me.  There will be any number of home-made


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.

--

[ message continues ]

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

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


I'll get rid of them.

Miklos
--

[ message continues ]

So, let's use /proc/mounts_v2  ;-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
--

[ message continues ]

Was not it like "don't use /proc for new things"?
--

[ message continues ]

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

[ message continues ]

Which automatically means "no sysfs".  We are NOT converting vfsmounts
to kobject-based lifetime rules.
--

[ message continues ]

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

[ message continues ]

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

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

[ message continues ]

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


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

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

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

[ message continues ]

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

 Exactly.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
--

[ message continues ]