linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: Denis Karpov <ext-denis.2.karpov@nokia.com>
Cc: hirofumi@mail.parknet.co.jp, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, adrian.hunter@nokia.com,
	artem.bityutskiy@nokia.com, akpm@linux-foundation.org
Subject: Re: [PATCH 0/5][V2] FS: userspace notification of errors
Date: Thu, 11 Jun 2009 15:26:39 +0200	[thread overview]
Message-ID: <ac3eb2510906110626i165aadf0ma57f320e7e8a2356@mail.gmail.com> (raw)
In-Reply-To: <1244723089-1145-1-git-send-email-ext-denis.2.karpov@nokia.com>

On Thu, Jun 11, 2009 at 14:24, Denis Karpov<ext-denis.2.karpov@nokia.com> wrote:

> There were several objections to uevent usage, mostly with argument that
> uevents are meant to be used within a device context. One might argue that
> uevents are tied to kobjects that are not only used to represent devices,
> but also for other things (/sys/modules, /sys/fs, /sys/firmware).

No, the objection was to use the underlying *device* as the source to
raise filesystem events. I don't think there are problems in general
with objects in /sys/fs/ sending events.

But, the remaining questions here are:
Do we really want superblocks exported in the global,
non-namespace-aware /sys? It might be wrong to export stuff from other
namespaces for filesytems which are irrelevant, and not even visible.
I'm not sure about this, and it needs careful evaluation. We once had
filesystem mount/umount uevents on block devices, and we needed to
remove them for that namespace reason.

If we go that road, do we want all filesystems export their
superblocks here, like e.g. /sys/fs/super/<maj>:<min>/, or is this
custom fs-specific, like this patch does.

> What is wrong with using uevents otherwise? What would be another way to
> asyncronousely notify userspace of things happening in kernel, other
> than though pseudo filesystem files (procfs, sysfs)?

The question is how to relay error details, and how to transport that
information to userpace. Uevents have no state, and the information is
lost after the event. Uevents can not block, they need to finish in
userspace immediately, you can not queue the up or anything else, it
would block other operations. Uevents can _never_ be used to transport
high frequent event streams. They might render the entire system
unusable, if you have lots of devices and many errors.

They could be used to get attention when a superblock does a one-time
transition from "clean" to "error", everything else would just get us
into serious trouble later.

Thanks,
Kay

  parent reply	other threads:[~2009-06-11 13:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-11 12:24 [PATCH 0/5][V2] FS: userspace notification of errors Denis Karpov
2009-06-11 12:24 ` [PATCH 1/5] FAT: add basic sysfs support Denis Karpov
2009-06-11 12:24   ` [PATCH 2/5] FAT: generalize errors and warning printing Denis Karpov
2009-06-11 12:24     ` [PATCH 3/5] FAT: notify userspace of fs errors through sysfs Denis Karpov
2009-06-11 12:24       ` [PATCH 4/5] FAT: notify userspace of fs errors with uevents Denis Karpov
2009-06-11 12:24         ` [PATCH 5/5] FAT: add 'notify' mount option Denis Karpov
2009-06-12  7:06         ` [PATCH 4/5] FAT: notify userspace of fs errors with uevents Denis Karpov
2009-06-11 13:26 ` Kay Sievers [this message]
2009-06-11 16:41   ` [PATCH 0/5][V2] FS: userspace notification of errors Jamie Lokier
2009-06-11 16:43     ` Kay Sievers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ac3eb2510906110626i165aadf0ma57f320e7e8a2356@mail.gmail.com \
    --to=kay.sievers@vrfy.org \
    --cc=adrian.hunter@nokia.com \
    --cc=akpm@linux-foundation.org \
    --cc=artem.bityutskiy@nokia.com \
    --cc=ext-denis.2.karpov@nokia.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).