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@xxxxxxxxxxx> 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-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
