On Fri, Jul 27, 2012 at 9:07 AM, Kevin Wolf <kw...@redhat.com> wrote:
> Am 27.07.2012 09:56, schrieb Stefan Hajnoczi:
>> On Thu, Jul 26, 2012 at 2:28 PM, Kevin Wolf <kw...@redhat.com> wrote:
>>> Am 25.07.2012 14:21, schrieb Stefan Hajnoczi:
>>>> +== Read-only access must still work ==
>>>> +read 512/512 bytes at offset 0
>>>> +512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>>>> +incompatible_features     0x1
>>>> +
>>>> +== Repairing the image file must succeed ==
>>>> +ERROR OFLAG_COPIED: offset=8000000000050000 refcount=0
>>>> +Repairing cluster 5 refcount=0 reference=1
>>>> +No errors were found on the image.
>>>> +incompatible_features     0x0
>>>
>>> I wonder what happened to the "The following inconsistencies were found
>>> and repaired" message. Most likely not a problem with qemu-iotests,
>>> though, but something unexpected in qemu-img.
>>
>> It's because opening a qcow2 image read/write when the dirty flag is
>> set causes a repair.  This accounts for the "Repairing cluster 5 ..."
>> message.
>>
>> Then qemu-img check -r all calls bdrv_check() on an already repaired
>> image file and we get the "No errors were found on the image".
>
> I see. Not exactly how it was intended... Do we need a BDRV_O_CHECK flag
> that prevents the automatic repair or should we just live with the
> suboptimal output when lazy refcounting is enabled?

You noticed the issue so others might notice it too.  I'll send a
patch including qcow2 and qed changes to fix this using BDRV_O_CHECK.

Stefan

Reply via email to