linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Denis Karpov <ext-denis.2.karpov@nokia.com>,
	axboe@kernel.dk, hirofumi@mail.parknet.co.jp,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, adrian.hunter@nokia.com,
	artem.bityutskiy@nokia.com
Subject: Re: [PATCH 0/4] FS: userspace notification of errors
Date: Thu, 4 Jun 2009 14:53:21 +0200	[thread overview]
Message-ID: <ac3eb2510906040553j294f1015wfb7deb4b4fc63afc@mail.gmail.com> (raw)
In-Reply-To: <20090603115611.6bbbaf55.akpm@linux-foundation.org>

On Wed, Jun 3, 2009 at 20:56, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed,  3 Jun 2009 18:05:14 +0300 Denis Karpov <ext-denis.2.karpov@nokia.com> wrote:

> hm, I'm uncertain on the desirability or otherwise of the overall feature.
>
> Are there users or distros or device manufacturers asking for this?
> Where did the requirement come from?

I think we really need something like this to propagate such errors to
userpace. Printing something to the kernel log is not an useful
interface in any way. But I don't think we want it that way, not with
uevents, not with sysfs, and not tied to block devices.

Uevents should not be used for error reporting, unless it is well
defined within the _device_ context, which a filesystem on top of a
blockdev isn't. We could argue to get events for bad blocks of a
device, but I don't think we want filesystem related stuff ever in
device uevents. For the same reason, there should be no unconditional
fs-specific sysfs file below a block device.

Block device interfaces for filesystems can not handle device-less
virtual mounts which are common these days. There is no direct
relation from the device to the filesystem - so this would only work
for simple direct mounts, which isn't sufficient for a higher-level
interface like this.

And I don't think we want several event sources for the same thing,
uevents _and_ pollable sysfs files.

We already raise events on /proc/self/mountinfo when the mount tree
changes, I guess that's where fs specific stuff belongs, and it will
work with all kind of filesystem setups, regardless of the devices
below it. This is also the established interface for flags and options
and the current state of the filesystem, and does not mix filesystem
options into block device interfaces.

/proc/self/mountinfo could also work properly with namespaces which
might have different meaning for a device in a different namespace.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2009-06-04 12:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-03 15:05 [PATCH 0/4] FS: userspace notification of errors Denis Karpov
2009-06-03 15:05 ` [PATCH 1/4] FS: filesystem corruption notification Denis Karpov
2009-06-03 15:05   ` [PATCH 2/4] FAT: generalize errors and warning printing Denis Karpov
2009-06-03 15:05     ` [PATCH 3/4] FAT: add 'notify' mount option Denis Karpov
2009-06-03 15:05       ` [PATCH 4/4] EXT2: " Denis Karpov
2009-06-03 19:00         ` Andrew Morton
2009-06-10 21:03         ` Pavel Machek
2009-06-03 18:59       ` [PATCH 3/4] FAT: " Andrew Morton
2009-06-03 18:58   ` [PATCH 1/4] FS: filesystem corruption notification Andrew Morton
2009-06-03 15:36 ` [PATCH 0/4] FS: userspace notification of errors Eric Sandeen
2009-06-03 18:56 ` Andrew Morton
2009-06-04  1:59   ` Jamie Lokier
2009-06-04  5:57   ` Artem Bityutskiy
2009-06-04 14:27     ` Denis Karpov
2009-06-10 21:05     ` Pavel Machek
2009-06-04 12:53   ` Kay Sievers [this message]
2009-06-04 14:29     ` Russell Cattelan
2009-06-05  7:25     ` Jon Masters
2009-06-05 11:07     ` Artem Bityutskiy
2009-06-05 11:51       ` Denis Karpov
2009-06-05 13:06         ` Kay Sievers
     [not found]         ` <ac3eb2510906050606u7527654dv789364549b36f3e7@mail.gmail.com>
2009-06-09 13:49           ` Jan Kara
2009-06-03 22:30 ` Jan Kara
2009-06-04  6:10   ` Artem Bityutskiy

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=ac3eb2510906040553j294f1015wfb7deb4b4fc63afc@mail.gmail.com \
    --to=kay.sievers@vrfy.org \
    --cc=adrian.hunter@nokia.com \
    --cc=akpm@linux-foundation.org \
    --cc=artem.bityutskiy@nokia.com \
    --cc=axboe@kernel.dk \
    --cc=ext-denis.2.karpov@nokia.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-ext4@vger.kernel.org \
    --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).