On Fri, Jun 5, 2009 at 13:51, Denis Karpov[off-list ref] wrote:

quoted

This is doable, e.g. in the form of optional fields "tag[:value]"
(field 7, Documentation/filesystems/proc.txti for mountinfo).

quoted

But is using procfs generally a good idea ? Last several years all a lot of
stuff moved out from procfs into sysfs. Not to forget what procfs is
originally meant for: storing the proceses related information.

Yeah, but mounted volumes are namespace dependent, and namespaces are
process dependent. So events for your current namespace wouldn't be
too bad here. There might be reasons we don't want the mountinfo file,
but the "use sysfs for new stuff" does not count in this case. :)

  As much as I don't like the using /proc/mountinfo for this, it also
has the advantage that it nicely solves the problem with a filesystem
being bind-mounted on several directories...  Otherwise you have to
solve the problem which mountpoint of the filesystem should be used
(especially because the real root of the filesystem need not be
accessible from the namespace of the process).

quoted

- /sys/fs seems to be a perfect fit for the purpose judging by ext4 example
cons:
- uevent interface is unneeded extra(?); can be made optional, per attribute

You can not pass the mount path with the uevent, like you example
shows, you just don't know that reliably, and there can be many mount
points.

How do you want to name the /sys/fs/ device? By "dev_t st_dev" or the
underlying block device name? How do you indentify the mountpoint in
your current namespace, of the device that raised the error? The event
might be for a filesystem you can not reach at all in your mount tree.

The /sys/fs/ approach sounds very much like an "export known
superblocks in /sys/fs/", something like this could be useful, but we
need to check carefully with other people what are the issues of such
an interface, and if there is something that should not be exported
that way.

How are device-less superblocks like btrfs handled in such an
interface, how is the device named, if it does not have a direct block
device underneath?

  Generally, it is an unclear question how should kernel identify a
filesystem where the problem happened. We could have a kobject for
superblock but it's still unclear how to map this to a device /
mountpoints because that's what userspace ultimately wants to tell the
sysadmin and possibly make some automated decision.
  What currently seems as the cleanest solution to me, is to add some
"filesystem identifier" field to /proc/self/mountinfo (which could be
UUID, superblock pointer or whatever) and pass this along with the error
message to userspace. Passing could be done either via sysfs (but I
agree it isn't the best fit because a filesystem need not be bound to a
device) or just via generic netlink (which has the disadvantage that you
cannot use the udev framework everyone knows)...

									Honza
-- 
Jan Kara [off-list ref]
SuSE CR Labs