[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.025 / U:5.928 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site