Re: [Qemu-devel] Re: Notes on block I/O data integrity

[Jamie Lokier <jamie@shareable.org>]

Christoph Hellwig wrote:
> On Wed, Aug 26, 2009 at 07:57:55PM +0100, Jamie Lokier wrote:
> > Christoph Hellwig wrote:
> > > > what about LVM? iv'e read somewhere that it used to just eat barriers
> > > > used by XFS, making it less safe than simple partitions.
> > > 
> > > Oh, any additional layers open another by cans of worms.  On Linux until
> > > very recently using LVM or software raid means only disabled
> > > write caches are safe.
> > 
> > I believe that's still true except if there's more than one backing
> > drive, so software RAID still isn't safe.  Did that change?
> 
> Yes, it did change. 

> I will recommend to keep doing what people caring for their data
> have been doing since these volatile write caches came up: turn them
> off.

Unfortunately I tried that on a batch of 1000 or so embedded thingies
with ext3, and the write performance plummeted.  They are the same
thingies where I observed lack of barriers resulting in filesystem
corruption after power failure.  We really need barriers with ATA
disks to get decent write performance.

It's a good recommendation though.

> That being said with the amount of bugs in filesystems related to
> write barriers my expectation for the RAID and device mapper code is
> not too high.

Turning off volatile write cache does not provide commit integrity
with RAID.

RAID needs barriers to plug, drain and unplug the queues across all
backing devices in a coordinated manner quite apart from the volatile
write cache.  And then there's still that pesky problem of writes
which reach one disk and not it's parity disk.

Unfortunately turning off the volatile write caches could actually
make the timing window for failure worse, in the case of system crash
without power failure.

-- Jamie