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é <berra...@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 :|
