proxmox-mirrors/qemu
1
0
Fork 0
mirror of https://git.proxmox.com/git/qemu synced 2025-08-16 10:49:03 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Documentation: Update block cache mode information

Browse Source 
Somehow we forgot to update this when cache=writeback became the
default. While changing the information on the default, also make the
description of all caches modes a bit more accurate.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
This commit is contained in:
Kevin Wolf 2012-11-21 12:26:56 +01:00
parent e9bff10f8d
commit a13e5e0557
1 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
qemu-options.hx
View File

@ -206,33 +206,33 @@ Open drive @option{file} as read-only. Guest write attempts will fail.
file sectors into the image file. file sectors into the image file.
@end table @end table
By default, writethrough caching is used for all block device. This means that By default, the @option{cache=writeback} mode is used. It will report data
the host page cache will be used to read and write data but write notification writes as completed as soon as the data is present in the host page cache.
will be sent to the guest only when the data has been reported as written by This is safe as long as your guest OS makes sure to correctly flush disk caches
the storage subsystem. where needed. If your guest OS does not handle volatile disk write caches
correctly and your host crashes or loses power, then the guest may experience
data corruption.
Writeback caching will report data writes as completed as soon as the data is For such guests, you should consider using @option{cache=writethrough}. This
present in the host page cache. This is safe as long as you trust your host. means that the host page cache will be used to read and write data, but write
If your host crashes or loses power, then the guest may experience data notification will be sent to the guest only after QEMU has made sure to flush
corruption. each write to the disk. Be aware that this has a major impact on performance.
The host page cache can be avoided entirely with @option{cache=none}. This will The host page cache can be avoided entirely with @option{cache=none}. This will
attempt to do disk IO directly to the guests memory. QEMU may still perform attempt to do disk IO directly to the guest's memory. QEMU may still perform
an internal copy of the data. an internal copy of the data. Note that this is considered a writeback mode and
the guest OS must handle the disk write cache correctly in order to avoid data
corruption on host crashes.
The host page cache can be avoided while only sending write notifications to The host page cache can be avoided while only sending write notifications to
the guest when the data has been reported as written by the storage subsystem the guest when the data has been flushed to the disk using
using @option{cache=directsync}. @option{cache=directsync}.
Some block drivers perform badly with @option{cache=writethrough}, most notably,
qcow2. If performance is more important than correctness,
@option{cache=writeback} should be used with qcow2.
In case you don't care about data integrity over host failures, use In case you don't care about data integrity over host failures, use
cache=unsafe. This option tells QEMU that it never needs to write any data @option{cache=unsafe}. This option tells QEMU that it never needs to write any
to the disk but can instead keeps things in cache. If anything goes wrong, data to the disk but can instead keep things in cache. If anything goes wrong,
like your host losing power, the disk storage getting disconnected accidentally, like your host losing power, the disk storage getting disconnected accidentally,
etc. you're image will most probably be rendered unusable. When using etc. your image will most probably be rendered unusable. When using
the @option{-snapshot} option, unsafe caching is always used. the @option{-snapshot} option, unsafe caching is always used.
Copy-on-read avoids accessing the same backing file sectors repeatedly and is Copy-on-read avoids accessing the same backing file sectors repeatedly and is