|| ||Chris Mason <chris.mason-AT-oracle.com>|
|| ||Jens Axboe <jens.axboe-AT-oracle.com>|
|| ||Re: [PATCH 0/4] (RESEND) ext3 barrier changes|
|| ||Tue, 20 May 2008 08:17:16 -0400|
|| ||Andrew Morton <akpm-AT-linux-foundation.org>,
Eric Sandeen <sandeen-AT-redhat.com>,
Theodore Tso <tytso-AT-mit.edu>, Andi Kleen <andi-AT-firstfloor.org>,
On Tuesday 20 May 2008, Jens Axboe wrote:
> On Mon, May 19 2008, Chris Mason wrote:
> > On Monday 19 May 2008, Chris Mason wrote:
> > > Here's a test workload that corrupts ext3 50% of the time on power fail
> > > testing for me. The machine in this test is my poor dell desktop
> > > (3ghz, dual core, 2GB of ram), and the power controller is me walking
> > > over and ripping the plug out the back.
> > Here's a new version that still gets about corruptions 50% of the
> > time, but does it with fewer files by using longer file names (240
> > chars instead of 160 chars).
> > 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.
> I ran this twice, killing power after 'renames ready'. The first time it
> was fine, the second time I got:
Great, thanks Jens.
So, one compromise may be to change the barriers on ext3 to look like the
patch Ted just sent out for ext4. It should be mostly safe to skip the
barrier between the log blocks and the commit block since the drive is likely
to do those sequentially anyway. A little extra logic could be added to
detect log wrapping and force an extra barrier in that case.
Reiserfs saw some significant performance gains when I changed the code from:
write log blocks
wait on log blocks
wait on commit
write log blocks
wait on all of them
Both were tested with the great big emc power failure machine and both passed.
In the event of an IO error on log blocks, we should zero out the commit.
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)