Thread (26 messages) 26 messages, 11 authors, 2008-05-21

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

From: Eric Sandeen <hidden>
Date: 2008-05-21 18:15:12
Also in: linux-fsdevel, lkml

Andrew Morton wrote:
On Wed, 21 May 2008 13:22:25 +0200 Pavel Machek [off-list ref] wrote:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help