[lkml]   [2008]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/4] (RESEND) ext3[34] barrier changes
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....


> 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
> More majordomo info at

 \ /
  Last update: 2008-05-17 00:05    [W:0.084 / U:0.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site