Am 07.08.2020 um 09:42 hat Ying Fang geschrieben:
On 8/6/2020 5:13 PM, Kevin Wolf wrote:
Am 05.08.2020 um 04:38 hat Ying Fang geschrieben:
From: fangying <fangying1@huawei.com>
When qemu or qemu-nbd process uses a qcow2 image and configured with
'cache = none', it will write to the qcow2 image with a cache to cache
L2 tables, however the process will not use L2 tables without explicitly
calling the flush command or closing the mirror flash into the disk.
Which may cause the disk data inconsistent with the written data for
a long time. If an abnormal process exit occurs here, the issued written
data will be lost.
Therefore, in order to keep data consistency we need to flush the changes
to the L2 entry to the disk in time for the newly allocated cluster.
Signed-off-by: Ying Fang <fangying1@huawei.com>
If you want to have data safely written to the disk after each write
request, you need to use cache=writethrough/directsync (in other words,
aliases that are equivalent to setting -device ...,write-cache=off).
Note that this will have a major impact on write performance.
cache=none means bypassing the kernel page cache (O_DIRECT), but not
flushing after each write request.
Well, IIUC, cache=none does not guarantee data safety and we should not
expect that. Then this patch can be ignored.
Indeed, cache=none is a writeback cache mode with all of the
consequences. In practice, this is normally good enough because the
guest OS will send flush requests when needed (e.g. because a guest
application called fsync()), but if the guest doesn't do this, it may
suffer data loss. This behaviour is comparable to a volatile disk cache
on real hard disks and is a good default, but sometimes you need a
writethrough cache mode at the cost of a performance penalty.