[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH v3] block/vdi: Use bdrv_flush after

From: phoeagon
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3] block/vdi: Use bdrv_flush after metadata updates
Date: Fri, 08 May 2015 11:50:29 +0000

In case of correctness, lacking a sync here does not introduce data corruption I can think of. But this reduces the volatile window during which the metadata changes are NOT guaranteed on disk. Without a barrier, in case of power loss you may end up with the bitmap changes on disk and not the header block, or vice versa. Neither introduces data corruption directly, but since VDI doesn't have proper fix mechanism for qemu-img, once the leak is introduced you have to "convert" to fix it, consuming a long time if the disk is large.

This patch does not fix the issue entirely, and it does not substitute for proper check-and-fix implementation. But this should bring about minor performance degradation (only 1 extra sync per allocation) but greatly reduces the metadata inconsistency window.

On Fri, May 8, 2015 at 6:43 PM Kevin Wolf <address@hidden> wrote:
Am 07.05.2015 um 06:04 hat Zhe Qiu geschrieben:
> From: phoeagon <address@hidden>
> In reference to b0ad5a455d7e5352d4c86ba945112011dbeadfb8~078a458e077d6b0db262c4b05fee51d01de2d1d2, metadata writes to qcow2/cow/qcow/vpc/vmdk are all synced prior to succeeding writes.

The justification for these patches (in 2010!) was more or less that we
didn't know whether the implementations were safe without the flushes.
Many of the flushes added back then have been removed again until today
because they have turned out to be unnecessary.

> Only when write is successful that bdrv_flush is called.
> Signed-off-by: Zhe Qiu <address@hidden>

Please describe why VDI needs this flush to be safe. This is best done
by describing a case where not doing the flush would lead to image
corruption in case of a crash.

To my knowledge, the VDI driver is completely safe without it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]