Re: [Qemu-devel] qcow2 - safe on kill? safe on power fail?

[Jamie Lokier <jamie@shareable.org>]

Anthony Liguori wrote:
> >What about SCSI or SATA NCQ?  On these, barriers don't impact 
> >performance greatly.
> 
> Good question, I don't know the answer.  But ext3 doesn't autodetect 
> SCSI/NCQ or anything.  It disabled barriers by default.  Some distros 
> have changed this behavior historically (SLES I believe).

Also don't forget XFS, Reiserfs.  I think they both use barriers by
default and have a correct fsync too.

SCSI/NCQ are detected by the block layer, as long as the filesystem
uses barriers.  Oh, and as long as not using LVM which doesn't pass on
barriers :/

> >>This is very hard to see happen in practice though because these 
> >>windows are very small--just like with QEMU.
>
> >The exposure window with qemu is not small.  It's as large as the page 
> >cache of the host.
> 
> Note I was careful to qualify my statements that cache=off was required.

Fair point.  Unfortunately cache=off introduces other exposure windows.

With cache=on, the multiple block writes to allocate a qcow2 sector
are in fast succession, so a QEMU crash (or signal) has to happen
during this short interval.

With cache=off, those writes will take as long as the disk seeks
between them, so there's a longer time window for a QEMU crash to
corrupt the file.

Also with cache=off, there's no disk barriers on any filesystem and
any filesystem options, so there's the additional time window of disk
cache inconsistency with the platters.

Databases face the same problem on Linux, but it's often ignored.
Does anyone know what Oracle on Linux does to keep it's structures
robust?

-- Jamie