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 <fangyi...@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 <fangyi...@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. Kevin
