Re: [Qemu-devel] Is cache=writeback safe yet?

[Kevin Wolf]

Am 20.02.2012 15:18, schrieb Virtbie:
> Dear qemuers,
> thanks for your exellent software.
> 
> I would like to use cache=writeback, but I still can't understand if 
> this is safe or not in case of power loss.
> In particular with virtio-blk on bare LVM device.
> 
> Qemu manpage still says cache=writeback isn't safe, but I seem to find 
> some discordant information reading around.
> 
> Is the WCE+volatile flag exposed to the guest already? I am logging into 
> a 2.6.38 guest and trying to find an indicator of disk cache in 
> /sys/block/vda/device but I am not able to. There is an obscure very 
> long "features" bitmask which I don't know what it shows. I think this 
> mode is not safe until WBC is exposed, AFAIU, right?

qemu exposes the WCE flag and if your guest handles it correctly (i.e.
it sends flush requests where needed), cache=writeback is safe. This is
true for recent Linux versions.

> Also please have a look at this:
> https://events.linuxfoundation.org/slides/2011/linuxcon-japan/lcj2011_hajnoczi.pdf
> page "Caching modes in Qemu"
> In the table it is written that writeback has "Guest disk write cache = on".
> Does that mean that the guest can commit to real platters by issuing a 
> flush on the virtual device?

Yes.

> So the problem lies in the fact that no guest will ever spontaneously 
> issue the flush because they don't see a wce=1?

This might have been true in very old versions of qemu, I'm not sure.
The real problem is that some guests could see the wce=1 if they
checked, but they simply don't care about it and don't send flushes anyway.

> There is another thing I don't understand:
> I think I read somewhere that cache=none is safer than cache=writeback. 
> Is that true? I think that both have a writeback cache, one is in the 
> physical disks attached to the host, the other is in the host's page 
> cache, so they should have about the same level of safety. What do you 
> think?

Yes, they are both considered writeback cache modes that require the
guest to issue flushes in order to be correct. The only difference is
that the cache is much bigger with cache=writeback (the whole host RAM
as opposed to a small disk cache).

> Lastly, regarding the newly introduced cache=directsync. Do I understand 
> correctly that it is supposed to be as safe as cache=writeback but also 
> as slow as cache=writeback, for writes, and in addition it cannot use 
> the host pagecache for reads, is that correct?

s/writeback/writethrough/ (I think this also is what you really meant)

Yes, it is a writethrough mode that doesn't use the host cache. Or
translated into open() flags, it's O_DIRECT | O_DSYNC. You usually don't
want to cache the data in the host because you already have a cache in
the guest. Caching twice is just a waste of memory. Also, Linux AIO only
works with O_DIRECT.

> BTW I also wanted to say I very much like the simplification proposed by 
> Anthony Liguori on 06/29/2011:
> 
>> Thinking twice about this, shouldn't we just move to a simplified model:
>>
>> -drive file=foo.img,cache=[on|off],hd0  -device 
>> virtio-blk-pci,drive=hd0,wce=1
> 
> splitting the cache features in two (host side / guest side) would very 
> much clarify what is happening in Qemu, for us ignorant users.

Yes, we're planning to move to something like this eventually.

Kevin