Re: JFYI: ext4 bug triggerable by kvm

[Christoph Hellwig <hch@infradead.org>]

On Tue, Aug 17, 2010 at 09:54:07AM -0500, Anthony Liguori wrote:
> This is simply unrealistic.  O_SYNC might force data to be on a
> platter when using a directly attached disk but many NAS's actually
> do writeback caching and relying on having an UPS to preserve data
> integrity.  There's really no way in the general case to ensure that
> data is actually on a platter once you've involved a complex storage
> setup or you assume FUA

Yes, there is.  If you have an array that has batter backup it handles
this internally.  The normal case is to not set the WCE bit in the
mode page, which tells the operating system not ever send
SYNCHRONIZE_CACHE commands.  I have one array that sets a WCE bit
neveless, but it also doesn't flush it's non-volatile cache in
SYNCHRONIZE_CACHE, but rather implements it as an effective no-op.

> Let me put it another way.  If an admin knows the disks on a machine
> have battery backed cache, he's likely to leave writeback caching
> enabled.
> 
> We are currently giving the admin two choices with QEMU, either
> ignore the fact that the disk is battery backed and do write through
> caching of the disk or do writeback caching in the host which

Again, this is not qemu's business at all.  Qemu is not different from
any other application requiring data integrity.  If that admin really
thinks he needs to overide the storage provided settings he can
mount the filesystem using -o nobarrier and we will not send cache
flushes.  I would in general recommend against this, as an external
UPS still has lots of failure modes that this doesn't account for.
Arrays with internal non-volatile memory already do the right thing
anyway.