From: Hans Reiser <reiser@namesys.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Kenichi Okuyama <okuyamak@dd.iij4u.or.jp>,
Andreas Dilger <adilger@clusterfs.com>,
fs <fs@ercist.iscas.ac.cn>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
zhiming@admin.iscas.ac.cn, qufuping@ercist.iscas.ac.cn,
madsys@ercist.iscas.ac.cn, xuh@nttdata.com.cn,
koichi@intellilink.co.jp, kuroiwaj@intellilink.co.jp,
okuyama@intellilink.co.jp, matsui_v@valinux.co.jp,
kikuchi_v@valinux.co.jp, fernando@intellilink.co.jp,
kskmori@intellilink.co.jp, takenakak@intellilink.co.jp,
yamaguchi@intellilink.co.jp, ext2-devel@lists.sourceforge.net,
shaggy@austin.ibm.com, xfs-masters@oss.sgi.com,
Reiserfs developers mail-list <Reiserfs-Dev@namesys.com>
Subject: Re: [Ext2-devel] Re: [RFD] FS behavior (I/O failure) in kernel summit
Date: Thu, 16 Jun 2005 12:08:02 -0700 [thread overview]
Message-ID: <42B1CE12.3090803@namesys.com> (raw)
In-Reply-To: <20050615225322.GB8584@thunk.org>
Theodore Ts'o wrote:
>
> It's better to
>have a separate, out-of-band notification scheme --- it's what dbus is
>really designed to be for.
>
>
If I understand you, you are saying don't change how we notify the app,
change how we notify the user and if it is the user that needs to act
then we should sidestep the app entirely by creating a new method that
talks to the user, including popping up a window if the user is using a
GUI, and doing some other configurable thing for other circumstances.
We could even create a mapping of errors to what the system should do in
response to them that the user can modify for the rare case that they
care to. Ok, I agree.
>
>
>>>Also, there is not neccesarily one right answer to how to respond to a
>>>underlying I/O error in the filesystem. So for ext2/3 filesystem, it
>>>is configurable.
>>>
>>>
>>>
>>>
>>Perhaps these policy choices should be mount options, what do you think?
>>
>>
>
>We put these policy options as options in the superblock, but there
>are some advantages in being able to override them at mount-time with
>mount options. For example, one such advantage is that we can
>standardize them across different filesystems.
>
>However, even if we do have standardized mount options, it is a real
>pain to have to type a very long mount option when doing manual
>mounts. So having defaults that can be stored in the superblock seems
>to be a good idea, in my opinion.
>
>
agreed.
> - Ted
>
>
>
>
next prev parent reply other threads:[~2005-06-16 19:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-13 19:53 [RFD] FS behavior (I/O failure) in kernel summit fs
2005-06-13 17:59 ` Hans Reiser
2005-06-13 20:13 ` [Ext2-devel] " Andreas Dilger
2005-06-13 23:56 ` Hans Reiser
2005-06-14 2:46 ` Kenichi Okuyama
2005-06-15 14:01 ` Theodore Ts'o
2005-06-15 19:40 ` Kenichi Okuyama
2005-06-15 20:29 ` Bernd Eckenfels
2005-06-15 20:37 ` Theodore Ts'o
2005-06-15 20:38 ` Hans Reiser
2005-06-15 22:53 ` Theodore Ts'o
2005-06-16 19:08 ` Hans Reiser [this message]
2005-06-16 11:52 ` Helge Hafting
2005-06-16 19:52 ` Hans Reiser
2005-06-16 21:27 ` Pavel Machek
2005-06-16 11:38 ` Matthew Wilcox
2005-06-14 12:51 ` Erik Mouw
2005-06-14 17:16 ` Kenichi Okuyama
2005-06-14 20:17 ` Szakacsits Szabolcs
2005-06-14 3:46 ` [Ext2-devel] " Valdis.Kletnieks
2005-06-14 17:41 ` fs
2005-06-13 21:51 ` Jeff Mahoney
2005-06-14 0:03 ` Hans Reiser
2005-06-15 17:39 ` Jeff Mahoney
2005-06-16 2:18 ` Dave Chinner
2005-06-16 15:21 ` Jeff Mahoney
2005-06-16 18:52 ` Hans Reiser
2005-06-14 13:22 ` Dave Kleikamp
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=42B1CE12.3090803@namesys.com \
--to=reiser@namesys.com \
--cc=Reiserfs-Dev@namesys.com \
--cc=adilger@clusterfs.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=fernando@intellilink.co.jp \
--cc=fs@ercist.iscas.ac.cn \
--cc=kikuchi_v@valinux.co.jp \
--cc=koichi@intellilink.co.jp \
--cc=kskmori@intellilink.co.jp \
--cc=kuroiwaj@intellilink.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=madsys@ercist.iscas.ac.cn \
--cc=matsui_v@valinux.co.jp \
--cc=okuyama@intellilink.co.jp \
--cc=okuyamak@dd.iij4u.or.jp \
--cc=qufuping@ercist.iscas.ac.cn \
--cc=shaggy@austin.ibm.com \
--cc=takenakak@intellilink.co.jp \
--cc=tytso@mit.edu \
--cc=xfs-masters@oss.sgi.com \
--cc=xuh@nttdata.com.cn \
--cc=yamaguchi@intellilink.co.jp \
--cc=zhiming@admin.iscas.ac.cn \
/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