From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Us7Ot-0004JZ-Qy for qemu-devel@nongnu.org; Thu, 27 Jun 2013 04:17:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Us7Or-0004AS-B3 for qemu-devel@nongnu.org; Thu, 27 Jun 2013 04:17:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Us7Or-0004AN-3T for qemu-devel@nongnu.org; Thu, 27 Jun 2013 04:17:53 -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 r5R8HqJH011221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Jun 2013 04:17:52 -0400 Date: Thu, 27 Jun 2013 10:17:50 +0200 From: Stefan Hajnoczi Message-ID: <20130627081750.GF13780@stefanha-thinkpad.redhat.com> References: <1372219161-12209-1-git-send-email-famz@redhat.com> <51CA96FC.1090907@redhat.com> <20130626073119.GB20711@t430s.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626073119.GB20711@t430s.nay.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 , qemu-devel@nongnu.org, kwolf@redhat.com, imain@redhat.com, rjones@redhat.com, roliveri@redhat.com, obarenbo@redhat.com, pmyers@redhat.com, armbru@redhat.com, eblake@redhat.com, hbrock@redhat.com On Wed, Jun 26, 2013 at 03:31:19PM +0800, Fam Zheng wrote: > On Wed, 06/26 09:23, Paolo Bonzini wrote: > > 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 Stefan