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(-)
