diff options
author | Richard W.M. Jones <rjones@redhat.com> | 2012-07-04 16:44:26 +0100 |
---|---|---|
committer | Richard W.M. Jones <rjones@redhat.com> | 2012-07-04 16:44:35 +0100 |
commit | 1b87f89b5c61f7b840663ddebaa58beb716bb1e9 (patch) | |
tree | 19f0072cf290e1e547cb23b7920b1259d1c7047d | |
parent | a95fc923880018e5e533d69ba2bef702e0f6dd3c (diff) | |
download | libguestfs-1b87f89b5c61f7b840663ddebaa58beb716bb1e9.tar.gz libguestfs-1b87f89b5c61f7b840663ddebaa58beb716bb1e9.tar.xz libguestfs-1b87f89b5c61f7b840663ddebaa58beb716bb1e9.zip |
todo: Investigate qemu caching modes.
-rw-r--r-- | TODO | 16 |
1 files changed, 16 insertions, 0 deletions
@@ -498,3 +498,19 @@ should. There is a command line tool designed for scripts called this approach works, it doesn't solve the MBR problem, so likely we'd have to write a library for that (or perhaps go back to sfdisk but using a very abstracted interface over sfdisk). + +qemu caching +------------ + +(Suggested by Paolo Bonzini and Kevin Wolf) + +Measure the effect of cache=none, cache=directsync, +cache=writethrough, cache=writeback. + +It's doubtful that using cache=none is useful, since it disables the +host cache making read-heavy workloads slower (they rely entirely on +the smaller appliance kernel's cache). And in libguestfs we don't +necessarily care about ongoing data integrity while writing, as long +as data is reliably written out when g.sync or g.close return. Also +in libguestfs we effectively control the whole stack, so we can ensure +write barriers happen when we want. |