From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdiQM-0002hN-T5 for qemu-devel@nongnu.org; Thu, 02 Apr 2015 12:57:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdiQL-0003Eo-JX for qemu-devel@nongnu.org; Thu, 02 Apr 2015 12:56:58 -0400 Message-ID: <551D74A9.9020306@redhat.com> Date: Thu, 02 Apr 2015 10:56:09 -0600 From: Eric Blake MIME-Version: 1.0 References: <20150402132857.GA26513@igalia.com> In-Reply-To: <20150402132857.GA26513@igalia.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t9gJFwxDV6AT3cohm4utiE8q54swpIDJh" Subject: Re: [Qemu-devel] [RFC] Intermediate block mirroring List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia , qemu-devel@nongnu.org, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t9gJFwxDV6AT3cohm4utiE8q54swpIDJh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/02/2015 07:28 AM, Alberto Garcia wrote: > Hi, >=20 > I'm interested in adding the possibility to mirror an intermediate > node in a disk image chain, but I would like to have some feedback > before sending any patches. >=20 > The goal would be to convert this: >=20 > [A] -> [B] -> [C] -> [D] >=20 > into this: >=20 > [A] -> [B] -> [X] -> [D] >=20 > where [D] is the active image and [X] would be a copy of [C]. The > latter would be unlinked from the chain. Seems useful, if for no other reason than to be another tool in the arsenal of low-level manipulations that can be strung together for cool high-level operations. >=20 > A use case would be to move disk images across different storage > backends. >=20 > My idea is to extend the drive-mirror command. Similar to what we > discussed in the case of the intermediate block streaming, I can reuse > the 'device' parameter to refer to a node name. So the API doesn't > need any changes other than the extended semantics for this parameter. >=20 > One difference with the current functionality is that once the block > job is completed, the node above the mirrored one would have to change > its backing image to point to the new one. One solution is to iterate > over all devices (bdrv_next()) and check which ones are connected > directly or indirectly to the mirrored node (bdrv_find_overlay()). >=20 > drive-mirror has three different sync modes: top, full and none. This > would be the chain from the example using each one of these modes: >=20 > top: >=20 > [A] -> [B] -> [X] -> [D] That is, X becomes the mirror of C, and then a later command lets us rebase D onto X (since we know the guest-visible contents accessible from X and C are identical). >=20 > full: >=20 > [X] -> [D] That is, X becomes the mirror of the full chain A through C, and then a later command lets us rebase D onto X (since we know the guest-visible contents accessible from X and C are identical). >=20 > none: >=20 > [A] -> [B] -> [C] -> [X] -> [D] That is, X becomes a new file that tracks changes made since a point in time which are also going into C; and if we desire we can issue a later command to rebase D onto X (since we know the guest-visible contents accessible from X and C are identical at that time), and even later start cleaning up C (we could use dirty bitmaps to see what got moved into X to clean those sectors out of C and reduce its size) >=20 > My understanding is that in the 'sync=3Dfull' case, [A] and [B] would > also need to be blocked during the operation since they are going to > disappear from the chain. >=20 > I have some code and in principle everything seems to be working fine, > but I'd like to test it a bit more. >=20 > What's anyway your opinion about this proposal? Certainly seems like something worth having. The devil may be in the details, but we can get there when you post proposed patches. >=20 > Thanks, >=20 > Berto >=20 >=20 >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --t9gJFwxDV6AT3cohm4utiE8q54swpIDJh 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVHXSpAAoJEKeha0olJ0NqsUsIAIbpINSlCX8rajMa2SAiKa1R B7Xan6PiFofM8YmUhyqSzYMUxLUro5S7h6Vwd9B7lAsmgCKmVWfYEepxjcWYQnq/ Bt6UNb6GnPeRCmxIBbb7IICLyRCzHow6MU25OqLtyKRBiW+V674Bl6YVkMrg99qK V6JNi0lpGtKi3YsYxLfBzx2dnqhKkfelKiNV8sr9h+Lr5uV16i39mnwW27sLDm7G yJjNUcQGR7c0lORpxmaJrhc14enEHRIArlz0aJT74imwjubU3H8e2Q+GAvbizNjp eKm5XNL9OVURpuxXRyHD32DLL54k+Ch9tOW7QmTeLbv6IF/G7XjQYuELNLHumpg= =A8k1 -----END PGP SIGNATURE----- --t9gJFwxDV6AT3cohm4utiE8q54swpIDJh--