Re: [Qemu-devel] [PATCH 2/2] qcow2: mark image as corrupt if failing during create

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Feb 19, 2019 at 10:11:58AM -0600, Eric Blake wrote:
> On 2/19/19 6:50 AM, Daniel P. Berrangé wrote:
> > During creation we write a minimal qcow2 header and then update it with
> > extra features. If the updating fails for some reason we might still be
> > left with a valid qcow2 image that will be mistakenly used for I/O. We
> > cannot delete the image, since we don't know if we created the
> > underlying storage or not. Thus we mark the header as corrupt to
> > prevents its later usage.
> 
> Should we unconditionally mark the image as corrupt at the time we write
> the minimal qcow2 header, and then update the image to non-corrupt on
> the final update?

That's a nice idea, but we call blk_new_open() half way through to
qcow2_co_create method to open the minimal image. If we mark it
corrupt upfront we'll never be able to open this minimal image.

Adding a flag to allow blk_new_open to ignore the "corrupt" marker
feels unplesant to me.

> 
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >  block/qcow2.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index ecc577175f..338513e652 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -3104,6 +3104,9 @@ qcow2_co_create(BlockdevCreateOptions *create_options, Error **errp)
> >  
> >      ret = 0;
> >  out:
> > +    if (ret < 0) {
> > +        qcow2_mark_corrupt(blk_bs(blk));
> > +    }
> 
> If ret < 0 because of an EIO error, this may also fail to write the
> change to the header. Hence my question as to whether this is too late.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|