On 10.05.2010, at 23:59, Anthony Liguori wrote: > On 05/10/2010 04:51 PM, Alexander Graf wrote: >> 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 block parameter to -drive called "flush" which >> allows a user to disable flushing in odd scenarios like the above. 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: >> > > This seems like it's asking for trouble to me. I'm not sure it's worth the > minor performance gain.
The gain is little on my netbook where I did the test on. This is part of performance regressions from 0.10 to 0.12 where we're talking build times of 2 minutes going to 30. While writeback was most of the chunk, flushing still at least doubled the build times which is unacceptable for us. I also fail to see where it's asking for trouble. If we don't flush volatile data, things are good, no? Alex