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 <kw...@redhat.com> 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 <phoea...@gmail.com> > > >--- > > > 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 >
