From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsLIA-0002ja-4b for qemu-devel@nongnu.org; Wed, 04 Jun 2014 20:12:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsLI3-0003bS-Vd for qemu-devel@nongnu.org; Wed, 04 Jun 2014 20:12:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsLI3-0003bF-Ml for qemu-devel@nongnu.org; Wed, 04 Jun 2014 20:12:19 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s550CG0k020675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 4 Jun 2014 20:12:17 -0400 Date: Wed, 4 Jun 2014 20:12:14 -0400 From: Jeff Cody Message-ID: <20140605001214.GA2639@localhost.localdomain> References: <538FA3C8.7000108@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <538FA3C8.7000108@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: Fam Zheng , "qemu-devel@nongnu.org" On Wed, Jun 04, 2014 at 04:55:04PM -0600, Eric Blake wrote: > Testing on Fedora 20 (JSON output slightly modified for legibility): > > $ qemu-kvm --version > QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice Bellard > $ touch f > $ qemu-kvm -qmp stdio -drive file=f > <= {"QMP": {"version": {"qemu": {"micro": 0, "minor": 0, "major": 2}, > "package": ""}, "capabilities": []}} > > {"execute":"qmp_capabilities"} > <= {"return": {}} > > {"execute":"blockdev-snapshot-sync","arguments":{"device":"ide0-hd0","snapshot-file":"g"}} > Formatting 'g', fmt=qcow2 size=0 backing_file='f' backing_fmt='raw' > encryption=off cluster_size=65536 lazy_refcounts=off > <= {"return": {}} > > {"execute":"block-commit","arguments":{"device":"ide0-hd0","top":"g"}} > {"timestamp": {"seconds": 1401921011, "microseconds": 498888}, "event": > "BLOCK_JOB_COMPLETED", "data": {"device": "ide0-hd0", "len": 0, > "offset": 0, "speed": 0, "type": "commit"}} > <= {"return": {}} > > {"execute":"query-block-jobs"} > <= {"return": []} > > 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: from block/mirror.c (active commit is a special mirror case): static void coroutine_fn mirror_run(void *opaque) { MirrorBlockJob *s = opaque; BlockDriverState *bs = s->common.bs; int64_t sector_num, end, sectors_per_chunk, length; uint64_t last_pause_ns; BlockDriverInfo bdi; char backing_filename[1024]; int ret = 0; int n; if (block_job_is_cancelled(&s->common)) { goto immediate_exit; } 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. -Jeff