From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsN6x-0006zk-9m for qemu-devel@nongnu.org; Wed, 04 Jun 2014 22:09:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsN6q-0002aU-Sm for qemu-devel@nongnu.org; Wed, 04 Jun 2014 22:08:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42433) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsN6q-0002aL-IC for qemu-devel@nongnu.org; Wed, 04 Jun 2014 22:08:52 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5528p3q023843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 4 Jun 2014 22:08:52 -0400 Date: Thu, 5 Jun 2014 10:09:06 +0800 From: Fam Zheng Message-ID: <20140605020906.GA10963@T430.nay.redhat.com> References: <538FA3C8.7000108@redhat.com> <20140605001214.GA2639@localhost.localdomain> <538FCDF2.4080409@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <538FCDF2.4080409@redhat.com> Subject: Re: [Qemu-devel] active block commit bug? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Jeff Cody , akong@redhat.com, "qemu-devel@nongnu.org" On Wed, 06/04 19:54, Eric Blake wrote: > On 06/04/2014 06:12 PM, Jeff Cody wrote: > > >> Huh? I thought that an active commit was not supposed to complete > >> automatically, but that the job would remain around until I either > >> 'block-job-cancel' or 'block-job-complete' it. That is, I should have > >> gotten a BLOCK_JOB_READY event and still see the job when I query for > >> it. Where am I going wrong, or did I uncover a bug in active commit? > >> > > > > I tried repeating your findings, but I couldn't, until I noticed that > > 'f' was just a 0-length raw image in your test. > > > > The snapshot file will be the same size, 0. So when we go to perform > > the active commit, we short-circuit at the beginning, since we are > > committing a zero-length image: > > That explains it. > > > > > s->common.len = bdrv_getlength(bs); > > if (s->common.len <= 0) { > > block_job_completed(&s->common, s->common.len); > > return; > > } > > ^^^^^ > > we exit early here, with a completed message, since there is > > nothing to do. > > > > If 'g' had increased to non-zero size, then you would have received a > > BLOCK_JOB_READY instead. > > Sounds like we have an off-by-one condition if empty files behave > differently from other files. We ought to fix that bug (not that your > normal guest will ever have a 0-length backing file, but this was what I > was trying to use for libvirt's probing of whether active commit is > supported) > Yes, agreed, this special case is only going to make management confused. I will send a patch to fix this. Eric, is this a good way to probe the active commit? I was expecting full instrospection of QMP could do it, but I don't know about the status of that piece of work. Amos, any ideas? Fam