Re: [PATCH 0/4] (RESEND) ext3[34] barrier changes

From: Eric Sandeen
Date: Fri May 16 2008 - 18:03:31 EST

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at