From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsCQW-0003n9-Me for qemu-devel@nongnu.org; Thu, 27 Jun 2013 09:40:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UsCQQ-0005oP-Ai for qemu-devel@nongnu.org; Thu, 27 Jun 2013 09:39:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsCQQ-0005oE-26 for qemu-devel@nongnu.org; Thu, 27 Jun 2013 09:39:50 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5RDdmVY012715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Jun 2013 09:39:49 -0400 Date: Thu, 27 Jun 2013 15:39:47 +0200 From: Stefan Hajnoczi Message-ID: <20130627133947.GB29628@stefanha-thinkpad.redhat.com> References: <1372219161-12209-1-git-send-email-famz@redhat.com> <51CA96FC.1090907@redhat.com> <20130626073119.GB20711@t430s.nay.redhat.com> <20130627081750.GF13780@stefanha-thinkpad.redhat.com> <51CC0EB4.2090505@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51CC0EB4.2090505@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 0/3] Point-in-time snapshot exporting with drive-backup List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, obarenbo@redhat.com, armbru@redhat.com, roliveri@redhat.com, hbrock@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, pmyers@redhat.com, imain@redhat.com On Thu, Jun 27, 2013 at 12:06:44PM +0200, Paolo Bonzini wrote: > Il 27/06/2013 10:17, Stefan Hajnoczi ha scritto: > >>> > > Il 26/06/2013 05:59, Fam Zheng ha scritto: > >>> > > This leads to another observation: a sync:'none' block-backup job > >>> > > probably should never complete, and should instead go on until explicit > >>> > > cancellation. This is because the job does no background writes, and > >>> > > thus completion would only happen after the guest has written the whole > >>> > > disk. Writing the whole disk is rare enough that it will likely cause > >>> > > bugs in the clients. It is easier just to never complete the job. > >>> > > > >> > > >> > Yes, the sync mode none will simply run forever until cancelled. > > There is a dedicated command to successfully complete a job: > > > > block-job-complete > > block-job-complete should only be called after a BLOCK_JOB_READY event, > but when would the backup job raise it? Immediately after starting? > > There is no behavioral difference in this case between cancel and > complete in fact as far as I understand, so I think cancelling the job > would match existing practice better. Okay. Ian Main also preferred using block-job-cancel without the BLOCK_JOB_READY/block-job-complete lifecycle. Thanks for the input! Stefan