Re: [Qemu-devel] [PATCH v2 5/5] block: add header update capability for VHDX images.

[Jeff Cody <jcody@redhat.com>]

On Sun, Apr 28, 2013 at 06:05:53PM +0800, Fam Zheng wrote:
> On Tue, 04/23 10:24, Jeff Cody wrote:
> >      if (flags & BDRV_O_RDWR) {
> > -        ret = -ENOTSUP;
> > -        goto fail;
> > +        vhdx_update_headers(bs, s, false);
> 
> Do we really have to update the header immediately on RW open? I assume
> when implementing vhdx_co_writev, this is guaranteed to get called
> before other write. In that case we don't need it here, which means we
> don't change anything if no user write, even for RW opened file.
>

There are two file modification GUIDS that need to be generated: a
'file write' guid, and a 'data write' guid.  The data write GUID
encompasses anything visible to the guest.  The file write GUID
includes any modifications to metadata.

This will update the file write GUID in the header, but not the data
write GUID.  According the spec, the file write GUID is for any data
modification, including metadata.   So once the log support is
implemented, we could latch that this has not occurred and do it
during a log write if we wanted (since all metdata updates will go
through the log).

In the vhdx_co_writev patches from the RFC, it does writes the data
guid if it detects it is the first write.

However, the spec says (with regard to the file write guid):

  "The parser can skip updating this field if the storage media on which
   the file is stored is read-only, or if the file is opened in read-only
   mode."

Which I think implies that we should go ahead and update the file
write guid field if the image is opened r/w.  This would also
encompass any modifications to resizing the image, changing backing
files (once differencing files are supported), which would not go
through vhdx_co_writev().

All that said, I am getting ready to submit v3, and I am dropping this
patch from the series for now.

Thanks,
Jeff