qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH v11 2/3] qemu-img info lists bitmap


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v11 2/3] qemu-img info lists bitmap directory entries
Date: Mon, 4 Feb 2019 11:37:48 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2/4/19 11:33 AM, Eric Blake wrote:
> On 2/4/19 10:46 AM, Vladimir Sementsov-Ogievskiy wrote:
> 
>>>
>>> Oops, hm, I now doubt, how Andrey's patches work, if bitmap_list_load 
>>> function
>>> fails when unknown flags are found. So, can we really show unknown-flags,
>>> or we'll fail if there any?
>>>
>>> And if we fail (I hope we fail) on unknown flags, than we don't need this
>>> field :).
>>>
>>
>> But we can update bitmap_list_load, to have a flag, and show bitmaps with
>> unknown flags in qemu-img info.. And we have to somehow not fail on open 
>> before
>> it. I'm very sorry that I understand it all only now :(.
>>
>> So, do we really need unknown-flags field? If yes, may be, do it as a next 
>> step?
>> And proceed now without them?
> 
> Good point about not even being able to open an image with unknown flags
> to be able to report on it (qemu-img check might want to be able to do
> it, but if qemu-img info refuses to open the image because of unknown
> flags, that's acceptable).  I'm good with your idea of skipping
> unknown-flags for now, and adding it in a later patch if it proves
> worthwhile.

It may also be worth an addition to iotests that intentionally corrupts
an image with persistent bitmaps to set an unknown bit, just to see how
qemu reacts to such an image.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]