[libvirt-users] Behavior of disk caching with qcow2 disks
Andrew Martin
amartin at xes-inc.com
Thu Aug 14 14:45:35 UTC 2014
----- Original Message -----
> From: "Kashyap Chamarthy" <kchamart at redhat.com>
>
> Looking at `qemu-img` source[1], 'cache=writeback' seems to be the
> default. That's also corroborated by this[2] (Rich's blog, and
> libguestfs/virt-tools lead developer).
>
>
> [1]
> http://git.qemu.org/?p=qemu.git;a=blob;f=qemu-img.c;h=d4518e724f848a6ff8ffaf61656d080de5a08f03;hb=HEAD#l55
> [2]
> http://rwmj.wordpress.com/2013/09/02/new-in-libguestfs-allow-cache-mode-to-be-selected/
>
> > Which is correct?
>
>
> "cache=writeback"
>
> > How is the cache mode set by default (if cache= is not
> > specified)?
>
> It's compiled into the binary.
>
> > My second question is can cache=none be used safely on a local ext4
> > filesystem with no BBU? Since ext4 uses barriers, would writing to
> > these qcow2 image files be safe? The kernel documentation about
> > barriers states that "Write barriers enforce proper on-disk ordering
> > of journal commits, making volatile disk write caches safe to use, at
> > some performance penalty". Does this apply to qcow2 VM images?
>
> FWIW, in my test environments (which I should admit - there's not a
> whole lot of I/O activity), I use:
>
> $ qemu-img create -f qcow2 -o preallocation=metadata test1.qcow2 8G
>
> Followed by an `fallocate`:
>
> $ fallocate -l 8589934592 test1.qcow2
>
> Then, I used to invoke QEMU "cache=none" (setting it in libvirt's guest
> XML), but lately started using the default "cache=writeback" after the
> I learnt about the bug from Rich's blog above.
>
> --
> /kashyap
>
Kashyap,
Thanks for the clarification. Rich's article seems to indicate that cache=writeback
is safe:
> writeback is the new, safe default. Flush commands are obeyed so as long as you’re
> using a journalled filesystem or issue guestfs_sync calls your data will be safe.
However, I have several VMs running on a server with qemu-kvm 1.4.0 and libguestfs 1.14.8
(older because this is Ubuntu 12.04) using the default cache mode, cache=writeback,
and recently this server's UPS experienced a fault so all of the VMs and host lost power.
After booting back up, I discovered that the filesystems on 3 of the guests were
corrupted, requiring an fsck with a lot of fixes. After fsck finished, data that had
been written within the last 24-48 hours on the disks appears to have been corrupted.
This makes me think that the data was never synced back to the disk, and would
indicate that I can't trust the guest's journalled filesystem. This data was written
several hours before the crash, so I would think that should be enough time for an
fsync to be called.
How can I guarantee the safety of written data on guests whose images are stored on
the following types of filesystems:
* local ext4 filesystem on a md RAID (no BBU)
* NFS mountpoint with the "sync" option
Thanks,
Andrew
More information about the libvirt-users
mailing list