[Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush v2

[Alexander Graf <agraf@suse.de>]

Thanks to recent improvements, qemu flushes guest data to disk when the guest
tells us to do so.

This is great if we care about data consistency on host disk failures. In cases
where we don't it just creates additional overhead for no net win. One such use
case is the building of appliances in SUSE Studio. We write the resulting images
out of the build VM, but compress it directly afterwards. So if possible we'd
love to keep it in RAM.

This patchset introduces a new cache option to -drive called "volatile" which
allows a user to signal qemu that he doesn't care about data integrity.
To show the difference in performance this makes, I have put together a small
test case. Inside the initrd, I call the following piece of code on a 500MB
preallocated vmdk image:

  mkfs.ext3 /dev/vda
  mkdir -p /mnt
  mount /dev/vda /mnt
  dd if=/dev/zero of=/mnt/test bs=1M
  umount /mnt
  sync
  halt -fp

With cache=writeback

real	0m34.653s
user	0m16.957s
sys	0m5.872s

With cache=volatile

real	0m27.068s
user	0m15.829s
sys	0m6.648s

When I use a loopback file with msdos format and put the vmdk inside there,
performance for cache=writeback and cache=volatile is basically identical.

It nevertheless does make sense to offer a cache=volatile option to the user,
as it's not always possible to loopback mount your own file systems, especially
given qemu's non-root nature.

v1 -> v2:

  - clean up no_op patch
  - move to cache=volatile instead of flush=off
  - make code less intrusive by catching everything in block.c

Alexander Graf (2):
  Add no-op aio emulation stub
  Add cache=volatile parameter to -drive

 block.c         |   28 ++++++++++++++++++++++++++++
 block.h         |    1 +
 qemu-config.c   |    2 +-
 qemu-options.hx |    7 ++++---
 vl.c            |    3 +++
 5 files changed, 37 insertions(+), 4 deletions(-)