From: Denis Karpov <ext-denis.2.karpov@nokia.com>
To: hirofumi@mail.parknet.co.jp
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
adrian.hunter@nokia.com, artem.bityutskiy@nokia.com,
akpm@linux-foundation.org, kay.sievers@vrfy.org
Subject: [PATCH 0/5][V2] FS: userspace notification of errors
Date: Thu, 11 Jun 2009 15:24:44 +0300 [thread overview]
Message-ID: <1244723089-1145-1-git-send-email-ext-denis.2.karpov@nokia.com> (raw)
Hello,
here's a set of patches that implement user space notification of file
system run-rim errors through sysfs/uevents. The first approach was
discussed here:
http://marc.info/?t=124404183600003&r=1&w=2
Reasons behind the feature are summarized here:
http://marc.info/?l=linux-kernel&m=124409549418926&w=2
Hand-held device with large (large => lengthy/expensive fsck process)
FAT volumes on MMC that are error prone, especially in the scenario
when these volumes are exported through g_file_storage as USB mass
storage to be used externally; instead of just remounting read-only
on 'run-rime' error, notify user space and expect it to do something
about fixing the FS.
Implementation summary:
- add sysfs support for FAT fs: per-mounted-volume kobject and sysfs
hierarchy under /sys/fs/fat. Same approach as used by ext4 and fuse.
(PATCH 1)
- introduce kobject attribute 'fs_fault' (/sys/fs/fat/<volume>/fs_fault);
the attribute is '0' on (re)mount and set to '1' upon an error. (PATCH 3)
FAT error reporting facilities had to be re-factored (PATCH 2) in
order to simplify sending error notifications. (PATCH 2)
- provide mechanism to optionally notify userspace of FAT fs volume
kobject's attribute changes with uevents. An uevent to be sent is of
tyme KOBJ_CHANGE, with environment variable 'NAME=value', where NAME
is capitalized name of the attribute.
(PATCH 4)
- add mount option 'notify', which will eneble sending uevents on a FAT
kobjects attributes; use it for 'fs_faults' attribute. (PATCH 5)
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).
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)?
Denis
next reply other threads:[~2009-06-11 12:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-11 12:24 Denis Karpov [this message]
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 ` [PATCH 0/5][V2] FS: userspace notification of errors Kay Sievers
2009-06-11 16:41 ` 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=1244723089-1145-1-git-send-email-ext-denis.2.karpov@nokia.com \
--to=ext-denis.2.karpov@nokia.com \
--cc=adrian.hunter@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=artem.bityutskiy@nokia.com \
--cc=hirofumi@mail.parknet.co.jp \
--cc=kay.sievers@vrfy.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).