From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sfb8H-0005Rm-P5 for qemu-devel@nongnu.org; Fri, 15 Jun 2012 14:20:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sfb8F-0006mv-IN for qemu-devel@nongnu.org; Fri, 15 Jun 2012 14:20:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53582) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sfb8F-0006m4-9k for qemu-devel@nongnu.org; Fri, 15 Jun 2012 14:20:27 -0400 Message-ID: <4FDB7CE7.7090005@redhat.com> Date: Fri, 15 Jun 2012 12:20:23 -0600 From: Eric Blake MIME-Version: 1.0 References: <1339772759-31004-1-git-send-email-pbonzini@redhat.com> <1339772759-31004-23-git-send-email-pbonzini@redhat.com> In-Reply-To: <1339772759-31004-23-git-send-email-pbonzini@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF5F5495384DD07EFA80D76DD" Subject: Re: [Qemu-devel] [RFC PATCH 22/36] block: add mirror job List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, lcapitulino@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF5F5495384DD07EFA80D76DD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/15/2012 09:05 AM, Paolo Bonzini wrote: > This patch adds the implementation of a new job that mirrors a disk to > a new image while letting the guest continue using the old image. > The target is treated as a "black box" and data is copied from the > source to the target in the background. >=20 > The mirror job is never-ending, but it is logically structured into > two phases: 1) copy all data as fast as possible until the target > first gets in sync with the source; 2) keep target in sync and > ensure that reopening to the target gets a correct (full) copy > of the source data. >=20 > The second phase is indicated by the progress in "info block-jobs" > reporting the current offset to be equal to the length of the file. > When the job is cancelled in the second phase, QEMU will run the > job until the source is clean and quiescent, then it will report > successful completion of the job. (Note that it could already happen > that management lost the race against QEMU and got a completion > event instead of cancellation). Is this paragraph still accurate? At any rate, it sounds a bit confusing - if I run 'block-job-cancel', do I get a 'complete' or a 'cancelled' event? Or is it a question of _which_ event I get depending on how a race goes? > + > + if (bdrv_get_dirty_count(bs) =3D=3D 0) { > + /* We're out of the streaming phase. From now on, if the > + * job is cancelled we will actually complete all pending > + * I/O and report completion, so that drive-reopen can be > + * used to pivot to the mirroring target. > + */ Comment is out of date since you are no longer proposing a drive-reopen, but block-job-complete. > ## > +# @MirrorSyncMode: > +# > +# An enumeration of possible behaviors for the initial synchronization= > +# phase of storage mirroring. > +# > +# @top: copies data in the topmost image to the destination > +# > +# @full: copies data from all images to the destination Do we ever want to support partial mirroring, the way we support partial block-stream? That is, given: A <- B <- C and creating a copy D, 'top' means D has B as a backing file, 'full' means D has no backing file, but to create D with A as a backing file, I would instead have to do a 'top' mirror, then complete, then do a regular block-stream for a partial pull. Deciding whether to support partial block mirror with anything more than top but less than full will impact whether my proposed libvirt virDomainBlockCopy() command needs an extra argument for naming the new base file in a partial mirror. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigF5F5495384DD07EFA80D76DD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJP23znAAoJEKeha0olJ0NqEncIAIJrT95ocfqd+Y+PjQ5othLu WG0xvVKQ6z6Q1kpuqjaU6wUwIfGLIp8tj3VIvA2NECGQUJxbwujU/ZnkBi5ZJfOv hHkVUdDG7PXzXXEuKa0jdQgc86zLReBKRYDbX7xQHaIkDDQZ276irv+Z8iTWLj1W XjBIlLsEnT7OsvutoleEeuYQothcPWDL4ERgDOxZYA4i1A5urxkIbkl7/Je3cBNZ iCK0Fx5APB54OP4VhOzjoaMy9x9dTmFvWCsB2q6iLb1e2Bd0yEflJvGTReMGkzNV t0mvW0M8zN/kUk6LyVWljLROsNgn9Cn2EcJu4JxAu3JLzvQnXOzzHNwx1Grie3k= =RVte -----END PGP SIGNATURE----- --------------enigF5F5495384DD07EFA80D76DD--