lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 31 Jul 2008 15:03:12 +0900
From:	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>
To:	Andreas Dilger <adilger@....com>
Cc:	Mike Snitzer <snitzer@...il.com>, akpm@...ux-foundation.org,
	sct@...hat.com, adilger@...sterfs.com,
	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org,
	jack@...e.cz, jbacik@...hat.com, cmm@...ibm.com, tytso@....edu,
	tglx@...utronix.de, yumiko.sugita.yf@...achi.com,
	satoshi.oshima.fk@...achi.com
Subject: Re: [PATCH 1/2] ext3: add an option to control error handling on file
    data

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@...achi.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ