On Friday 16 May 2008, Andrew Morton wrote:

On Fri, 16 May 2008 20:20:30 -0400 Theodore Tso [off-list ref] wrote:

quoted

On Fri, May 16, 2008 at 11:53:04PM +0100, Jamie Lokier wrote:

quoted

quoted

quoted

If you just want to test the block I/O layer and drive itself,
don't use the filesystem, but write a program which just access the
block device, continuously writing with/without barriers every so
often, and after power cycle read back to see what was and wasn't
written.

Well, I think it is worth testing through the filesystem, different
journaling mechanisms will probably react^wcorrupt in different ways.

I agree, but intentional tests on the block device will show the
drives characteristcs on power failure much sooner and more
consistently.  Then you can concentrate on the worst drivers :-)

I suspect the real reason why we get away with it so much with ext3 is
that the journal is usually contiguous on disk, hence, when you write
to the journal, it's highly unlikely that commit block will be written
and the blocks before the commit block have not.

yup.  Plus with a commit only happening once per few seconds, the time
window for a corrupting power outage is really really small, in
relative terms.  All these improbabilities multiply.

Well, the barriers happen like so (even if we actually only do one barrier in 
submit_bh, it turns into two)

write log blocks
flush #1
write commit block
flush #2
write metadata blocks

I'd agree with Ted, there's a fairly small chance of things get reordered 
around flush #1.  flush #2 is likely to have lots of reordering though.  It 
should be easy to create situations where the metadata for a transaction is 
written before the log blocks ever see the disk.

EMC did a ton of automated testing around this when Jens and I did the initial 
barrier implementations, and they were able to trigger corruptions in fsync 
heavy workloads with randomized power offs.  I'll dig up the workload they 
used.

-chris