From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Us96M-0007Xd-KI for qemu-devel@nongnu.org; Thu, 27 Jun 2013 06:06:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Us96K-000229-O7 for qemu-devel@nongnu.org; Thu, 27 Jun 2013 06:06:54 -0400 Received: from mail-bk0-x231.google.com ([2a00:1450:4008:c01::231]:58602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Us96K-00021v-Im for qemu-devel@nongnu.org; Thu, 27 Jun 2013 06:06:52 -0400 Received: by mail-bk0-f49.google.com with SMTP id mz10so204232bkb.22 for ; Thu, 27 Jun 2013 03:06:51 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51CC0EB4.2090505@redhat.com> Date: Thu, 27 Jun 2013 12:06:44 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <20130627081750.GF13780@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Stefan Hajnoczi 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 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. Paolo