Am 08.05.2015 um 13:50 hat phoeagon geschrieben: > 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 is true. I'm not sure how big a problem this is in practice, though. > 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. Did you benchmark this? From the past experience with flushes in qemu block drivers, one sync per allocation certainly doesn't sound "minor". What could possibly save us from the worst is that VDI has a relatively large block size (or rather, that we don't support images with different block sizes). Kevin
