Then I would guess the same reason should apply to VMDK/VPC as well... Their metadata update protocol is not atomic either, and a sync after metadata update doesn't fix the whole thing theoretically either. Yet the metadata sync patches as old as since 2010 are still there. It should also be a performance boost if we remove those write barriers as well, if conversion performance is our major concern.
I think when converting images, one can always opt for "cache=unsafe" to avoid potential performance degradation from conservative cache (it should really be default for qemu-img convert, but I don't know if it's the case), so conversion performance shouldn't be a reason to sacrifice VM-runtime consistency.
On Fri, May 8, 2015 at 9:55 PM Kevin Wolf <
address@hidden> wrote:
Am 08.05.2015 um 15:14 hat Max Reitz geschrieben:
> On 07.05.2015 17:16, Zhe Qiu wrote:
> >In reference to b0ad5a45...078a458e, metadata writes to
> >qcow2/cow/qcow/vpc/vmdk are all synced prior to succeeding writes.
> >
> >Only when write is successful that bdrv_flush is called.
> >
> >Signed-off-by: Zhe Qiu <address@hidden>
> >---
> > block/vdi.c | 3 +++
> > 1 file changed, 3 insertions(+)
>
> I missed Kevin's arguments before, but I think that adding this is
> more correct than not having it; and when thinking about speed, this
> is vdi, a format supported for compatibility.
If you use it only as a convert target, you probably care more about
speed than about leaks in case of a host crash.
> So if we wanted to optimize it, we'd probably have to cache multiple
> allocations, do them at once and then flush afterwards (like the
> metadata cache we have in qcow2?)
That would defeat the purpose of this patch which aims at having
metadata and data written out almost at the same time. On the other
hand, fully avoiding the problem instead of just making the window
smaller would require a journal, which VDI just doesn't have.
I'm not convinced of this patch, but I'll defer to Stefan Weil as the
VDI maintainer.
Kevin