Re: [Qemu-discuss] Understanding QEMU Cache Modes and Emulated Disk Write Cache

[Jakob Bohm]

On 17/08/2016 16:56, Andrew Martin wrote:
> ----- Original Message -----
> > From: "Jakob Bohm" <address@hidden>
> > To: address@hidden
> > Sent: Wednesday, August 17, 2016 9:34:32 AM
> > Subject: Re: [Qemu-discuss] Understanding QEMU Cache Modes and Emulated Disk 
> > Write Cache
> >
> > On 17/08/2016 15:21, Andrew Martin wrote:
> > > According to this page, cache=writeback enables the disk write cache:
> > > http://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatbpkvmguestcache.htm
> > >
> > > Is this the write cache on the physical disk itself, or the write cache on
> > > the
> > > qcow2 image (does the qcow2 even have a disk write cache)? Does this cache
> > > get
> > > bypassed when fdatasync(2) calls come in from the guest?
> > >
> > > When is the guest's page cache ever used?
> > Whenever the Guest OS feels like it, because the Guest OS doesn't (in
> > principle) know the virtual disk is virtual.
> Would this primarily be for reads then, since write(2) is written to the host
> page cache?

The write(2) calls we are talking about are the virtual hardware disk
writes done by the guest OS, qemu does not know or care if the Guest OS
caches data before doing those writes.

> Does QEMU create an emulated disk cache for the qcow2 image, or is that just
> the host page cache?

I don't know.  I presume that qemu at least keeps some of the qcow2
metadata in memory to avoid excessive host disk I/O.

> > > Let me see if I understand this correctly:
> > >
> > > cache=writeback - data stored in host page cache, guest responsible for
> > > issuing
> > > periodic fdatasync(2) calls; host disk cache enabled but never really used
> > > due
> > > to large amount of RAM available on host
> > Guest issues virtual "virtual disk hardware cache flushes", which are
> > turned into fdatasync(2) calls on host.
> So if I strace the qemu process (irrespective of the OS the guest is running)
> and I see fdatasync(2) calls coming through at regular intervals, 
> cache=writeback
> should be safe, correct?
>
> The delay between when the data is written and when it is flushed to permanent
> storage is just the period between subsequent fdatasync(2) calls, right?
>
> > Host disk cache enabled, but not very useful because most of the data
> > in it is probably also in the host page cache.
> > > cache=writethrough - data stored in host page cache, host issues
> > > fdatasync(2)
> > > immediately after write(2); host disk cache disabled
> > Host disk cache enabled, but flushed (at least the relevant parts) by
> > the fdatasync(2) calls.
> >
> > > cache=none - data is written directly to the host disk cache, guest
> > > responsible
> > > for issuing periodic fdatasync(2) calls
> > With the caveat above about what the the guest actually issues to cause
> > host side fdatasync(2) calls.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded