Use O_DSYNC by default and update documentation to explain IO integrity in QEMU
RFC 1/1 Use O_DSYNC by default and update documentation to explain IO integrity in QEMU
We'll have some benchmarks later this afternoon.
Regards,
Anthony Liguori
block-raw-posix.c +2 -2
@@ -120,7 +120,7 @@ static int raw_open(BlockDriverState *bs, const char *filename, int flags) s->lseek_err_cnt =0 ; - open_flags =O_BINARY ; + open_flags =O_BINARY |O_DSYNC ;if ((flags &BDRV_O_ACCESS ) ==O_RDWR ) { open_flags |=O_RDWR ; }else {
@@ -996,7 +996,7 @@ static int hdev_open(BlockDriverState *bs, const char *filename, int flags) IOObjectRelease( mediaIterator ); }#endif - open_flags =O_BINARY ; + open_flags =O_BINARY |O_DSYNC ;if ((flags &BDRV_O_ACCESS ) ==O_RDWR ) { open_flags |=O_RDWR ; }else {
qemu-doc.texi +44 -1
57 lines not on this page · raw message
qemu-doc.texi These options have the same definition as they have in @option{-hdachs}. · line 278
Quoted 4 lines · Anthony Liguori
qemu-doc.texi +2
-0+By default, QEMU accesses all disk data through the host's page cache. +This allows the host to perform read-ahead and to avoid duplicating IO
The guest does read-ahead as well, so this is not a good thing. Further, if using qcow2, host read ahead will read random data, and if using raw devices, host read ahead is equivalent to physical read ahead, whereas most OSes prefer logical (file based) read ahead.
qemu-doc.texi These options have the same definition as they have in @option{-hdachs}. · line 283
Quoted 6 lines
qemu-doc.texi +5
-0+requests unnecessarily increasing disk performance. You may notice that +certain benchmarks in the guest perform better than they do in the host +(for read) because of this. This is primarily because the benchmark is +unaware of the extra level of caching that is occurring when running in +a virtual environment.
This is because the the guest is effectively running with a much larger cache. If you'd given the guest this memory, it would perform even better.
IMO the only case where having the cache in the host is preferable is when the guest cannot utilize the memory effectively, such as when the guest reboots, or with older versions of Windows x86.
qemu-doc.texi These options have the same definition as they have in @option{-hdachs}. · line 290
Quoted 8 lines
qemu-doc.texi +7
-0+ +The cache=off option can be used to disable the use of the host's page +cache. Disabling the use of the host's page cache will likely reduce +performance since the host is unable to perform read-ahead and unable +to avoid duplicating IO requests. At this time, QEMU will copy data +internally so the cost of copying data into the host's page cache is +unlikely to be statistically significant.
It's a mistake to optimize for the current state of affairs which we are planning to change soon.
qemu-doc.texi These options have the same definition as they have in @option{-hdachs}.
Quoted 5 lines
qemu-doc.texi +5
-0+In the future, QEMU will be able to avoid copying data internally and +under certain workloads, disabling the use of the host's page cache may +increase performance provided that the guest is actively working to avoid +bringing data into the CPU's cache. This can only be achieved when using +things like sendfile() in the guest or other forms of direct-io.
Guest read ahead, write back, and pageout are also examples of transfers that are very likely to benefit from not touching the cache. Other examples are the guest reading a metadata block and only accessing one inode.
Signature · 2 lines
I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.