From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SufaT-0008Kt-Hh for qemu-devel@nongnu.org; Fri, 27 Jul 2012 04:07:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SufaN-0006p3-Rr for qemu-devel@nongnu.org; Fri, 27 Jul 2012 04:07:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21571) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SufaN-0006oi-IN for qemu-devel@nongnu.org; Fri, 27 Jul 2012 04:07:47 -0400 Message-ID: <50124C4D.6020407@redhat.com> Date: Fri, 27 Jul 2012 10:07:41 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1343218884-14980-1-git-send-email-stefanha@linux.vnet.ibm.com> <1343218884-14980-8-git-send-email-stefanha@linux.vnet.ibm.com> <501145F7.6010705@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 7/7] qemu-iotests: add 039 qcow2 lazy refcounts test List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Khoa Huynh , Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org Am 27.07.2012 09:56, schrieb Stefan Hajnoczi: > On Thu, Jul 26, 2012 at 2:28 PM, Kevin Wolf 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? Kevin