Jamie Lokier wrote: > Andrew Morton wrote: >>> I suppose alternately I could send another patch to remove "remember >>> that ext3/4 by default offers higher data integrity guarantees than >>> most." from Documentation/filesystems/ext4.txt ;) >> We could add a big scary printk at mount time and provide a document? > > Can I suggest making /proc/mounts say "barrier=0" when journal is not > enabled, instead of omitting the option. > > Boot logs are too large to pay close attention to unless it's really > obvious. (2.4 kernels _do_ have a similar message about "data > integrity not guaranteed" with USB drivers - I never understood what > it was getting it, and why it was removed for 2.6). > > However, if I saw barrier=0 in /proc/mounts it would at least prompt > me to look it up and then making an informed decision. Right now, ext3_show_options has the scheme: /* * Show an option if * - it's set to a non-default value OR * - if the per-sb default is different from the global default */ so only non-default is shown, so today barrier=0 is not shown. I suppose that could be changed... FWIW, my patch would show barrier=0 if it's manually mounted that way (against new proposed defaults), or if we are running w/o barriers due to a failed barrier IO even though barriers were requested. > Personally I had assumed barriers were enabled by default with ext3, > as some distros do that, the 2.4 patches did that, and: > > I *have* experienced corruption following power loss without > barriers, and none with barriers. > > When I mentioned that turning off write cache or using barriers is > a solution to a programmer working on the same project, she said > "oh, yes, we've had reports of disk corruption too - thanks for the > advice", and the advice worked, so I am not the only one. > > (In the interests of perspective, that's with ext3 on patched 2.4 > kernels on a ARM device, but still - the barriers seem to work). > > On a related note, there is advice floating about the net to run with > IDE write cache turned off if you're running a database and care about > integrity. That has much worse performance than barriers. ... and I've seen hand-waving about shortened drive life running this way? but who really knows.... Thanks, -Eric > I guess the patch which fixes fsync is particularly useful for those > database users, as it means they can run with write cache enabled and > depend on fsync() to give equivalent integrity now. (Enabling > journalling is not really relevant to this). > > -- Jamie > > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
