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. :)
> /proc/self/mountinfo solution:
> pros:
> - existing solution
> cons:
> - polling only
> - dedicated userspace tool to poll/parse/act
> - additional parsing overhead and event filtering (mountinfo changes for many
> reasons)
> - probably this info does not belong to procfs
Userspace polls it today already on most boxes, to find out if and
where something was mounted.
> /sys/fs/<fs>/<volume>/{attributes,..} solution:
> pros:
> - nice hierarchy reflecting structure of entities in the kernel
> - extensible (other errors, conditions, events can be reflected)
> - no parsing: dedicated file for each attribute
> - uevent interface with existing userspace tool (udev);
> (polling is still possible)
The uevent interface would need a rate limit inside the kernel.
Uevents are very expensive in userspace and you need to make sure,
that such an error reporting can never raise hundreds or thousands of
events, in no situation.
> - /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?
In any case, we definitely need something better than dmesg to pass
filesystem errors from the kernel to userspace, so this discussion is
much appreciated.
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
