[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2 7/7] qemu-iotests: add 039 qcow2 lazy refcoun

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2 7/7] qemu-iotests: add 039 qcow2 lazy refcounts test
Date: Mon, 30 Jul 2012 11:09:02 +0100

On Fri, Jul 27, 2012 at 9:07 AM, Kevin Wolf <address@hidden> wrote:
> Am 27.07.2012 09:56, schrieb Stefan Hajnoczi:
>> On Thu, Jul 26, 2012 at 2:28 PM, Kevin Wolf <address@hidden> 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.


reply via email to

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