Re: [PATCH 0/4] FS: userspace notification of errors

[Jan Kara]

> On Fri, Jun 5, 2009 at 13:51, Denis Karpov<ext-denis.2.karpov@xxxxxxxxx> wrote:
> > This is doable, e.g. in the form of optional fields "tag[:value]"
> > (field 7, Documentation/filesystems/proc.txti for mountinfo).
> 
> > 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).

> > - /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 <jack@xxxxxxx>
SuSE CR Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/