Andrew Morton wrote: > On Wed, 21 May 2008 13:22:25 +0200 Pavel Machek <pavel@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
