From: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
To: Andreas Dilger <adilger@sun.com>
Cc: Mike Snitzer <snitzer@gmail.com>,
akpm@linux-foundation.org, sct@redhat.com, adilger@clusterfs.com,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
jack@suse.cz, jbacik@redhat.com, cmm@us.ibm.com, tytso@mit.edu,
tglx@linutronix.de, yumiko.sugita.yf@hitachi.com,
satoshi.oshima.fk@hitachi.com
Subject: Re: [PATCH 1/2] ext3: add an option to control error handling on file data
Date: Thu, 31 Jul 2008 15:03:12 +0900 [thread overview]
Message-ID: <489155A0.2070208@hitachi.com> (raw)
In-Reply-To: <20080730211703.GZ3342@webber.adilger.int>
Andreas Dilger wrote:
> On Jul 30, 2008 11:14 -0400, Mike Snitzer wrote:
>
>>On Tue, Jul 29, 2008 at 10:52 PM, Hidehiro Kawai
>><hidehiro.kawai.ez@hitachi.com> wrote:
>>>If you mount a ext3 fs with data_err=abort option, it aborts on file
>>>data write error. If you mount it with data_err=ignore, it doesn't
>>>abort, just call printk(). data_err=abort is default, because
>>>people have used this error handling policy for three years.
>>
>>Thanks for making this configurable!
>>
>>But given how surprised many of us were when we found out that
>>jbd/ext3 has been aborting on file data blocks isn't this our chance
>>to correct that long-standing oversight? Shouldn't the default be
>>data_err=ignore? Or would changing this behavior cause more harm than
>>good?
I asked Japanese server vendor's people which default is preferred,
and they agreed on data_err=abort. But it would not be true for
all users all over the world.
>>I don't feel strongly either way, having the "data_err" option makes
>>this issue moot for me, but I figured I'd raise the question (in the
>>interest of review).
>
> Yes, good point. I don't think any of the ext3 maintainers were aware
> that the 3-years-old patch had introduced "abort on data error" behaviour.
> The default for ext4 is only now going to errors=remount-ro from
> errors=continue (as it is on ext2/3) so I think it is inconsistent to
> have the journal abort on data errors when the filesystem itself does not.
It's good point. Well, how about setting the default depending on
"errors" option? It means the default is data_err=ignore on
errors=continue and data_err=abort on errors=remount-ro/panic.
If it is confusing, I don't mind if the default is simply
data_err=ignore.
Thanks,
--
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center
next prev parent reply other threads:[~2008-07-31 6:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-30 2:52 [PATCH 1/2] ext3: add an option to control error handling on file data Hidehiro Kawai
2008-07-30 3:01 ` [PATCH 2/2] jbd: ordered data integrity fix Hidehiro Kawai
2008-07-30 15:14 ` [PATCH 1/2] ext3: add an option to control error handling on file data Mike Snitzer
2008-07-30 21:17 ` Andreas Dilger
2008-07-31 6:03 ` Hidehiro Kawai [this message]
2008-08-05 6:07 ` [PATCH 1/2] ext3: add an option to control error handling on file data (another ver.) Hidehiro Kawai
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=489155A0.2070208@hitachi.com \
--to=hidehiro.kawai.ez@hitachi.com \
--cc=adilger@clusterfs.com \
--cc=adilger@sun.com \
--cc=akpm@linux-foundation.org \
--cc=cmm@us.ibm.com \
--cc=jack@suse.cz \
--cc=jbacik@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=satoshi.oshima.fk@hitachi.com \
--cc=sct@redhat.com \
--cc=snitzer@gmail.com \
--cc=tglx@linutronix.de \
--cc=tytso@mit.edu \
--cc=yumiko.sugita.yf@hitachi.com \
/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).