lkml.org 
[lkml]   [2008]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] (RESEND) ext3[34] barrier changes
Andrew Morton wrote:
> On Wed, 21 May 2008 13:22:25 +0200 Pavel Machek <pavel@suse.cz> wrote:

>>> I tested this one with a larger FS (40GB instead of 2GB) and larger log (128MB
>>> instead of 32MB). barrier-test -s 32 -p 1500 was still able to get a 50%
>>> corruption rate on the larger FS.
>> Ok, Andrew, is this enough to get barrier patch applied and stop
>> corrupting data in default config, or do you want some more testing?
>>
>> I guess 20% benchmark regression is bad, but seldom and impossible to
>> debug data corruption is worse...
>
> It is 20%? I recall 30% from a few years ago, but that's vague and it
> might have changed. Has much quantitative testing been done recently?
> I might have missed it.
>
> If we do make this change I think it should be accompanied by noisy
> printks so that as many people as possible know about the decision
> which we just made for them.
>
> afaik there is no need to enable this feature if the machine (actually
> the disks) are on a UPS, yes?

As long as your power supply (or your UPS) doesn't go boom, I suppose so.

It is too bad that there is no way to determine no-barrier safety from
software. (maybe apcupsd could do something... ;)

I guess it's levels of confidence. I agree that a user education
campaign is probably in order... maybe if this thread is long enough to
make LWN it'll raise some awareness. :)

-Eric


\
 
 \ /
  Last update: 2008-05-21 20:23    [W:0.082 / U:1.040 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site