From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKCHk-0001wy-5D for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:06:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKCHi-0003u0-Qa for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:06:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16913) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKCHi-0003tr-I9 for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:06:02 -0400 Message-ID: <506F2187.6050403@redhat.com> Date: Fri, 05 Oct 2012 12:05:59 -0600 From: Eric Blake MIME-Version: 1.0 References: <1348855033-17174-1-git-send-email-kwolf@redhat.com> <1348855033-17174-13-git-send-email-kwolf@redhat.com> <506F190F.90100@redhat.com> In-Reply-To: <506F190F.90100@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC8B70313515BC170BE7A419F" Subject: Re: [Qemu-devel] [PATCH 12/30] QAPI: add command for live block commit, 'block-commit' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, anthony@codemonkey.ws This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC8B70313515BC170BE7A419F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/05/2012 11:29 AM, Eric Blake wrote: >=20 > which uses the absolute file name base->filename and fails to find base= , > making it impossible to commit into a base file that was referenced via= > relative name in the chain. I think that bdrv_find_backing_image needs= > to canonicalize any relative name passed in on input relative to the > directory of the bs where it is starting the search, and then search fo= r > absolute name matches rather than the current approach of searching for= > exact string matches (even if the exact string is a relative name). >=20 > Also, consider this case of mixed relative and absolute backing files i= n > the chain: >=20 > /dir1/base <- /dir1/file1(base) <- /dir2/base(/dir1/file1) <- > /dir2/file2(base) >=20 > The relative name 'base' appears twice in the chain, so you either have= > to declare it ambiguous, or else declare that relative names are > canonicalized relative to the starting point (such that > bdrv_find_backing_image(/dir1/file1, "base") gives a different result > than bdrv_find_backing_image(/dir2/file2, "base"). Which means, if I > request block-commit "top":"/dir1/file1", "base":"base", am I requestin= g > a commit into /dir1/base (good) or into /dir2/base (swapped arguments)?= Related question: /dir/base <- /dir/snap1(base) <- /dir/active(/dir/snap1) If I commit snap1 into base, should /dir/active encode the backing file as '/dir/base' (keep things absolute, since /dir/active had already been absolute) or as 'base' (relative, since the part of the chain previously referring to base was using relative). And if we store relative names, we need to make sure that the relative name stored in /dir/active correctly points to the correct file name, even if the ultimate base file lives in a different directory (similar problems exist with relative chains during block pull). I'm wondering if this means 'block-stream' and 'block-commit' both need to add @mode:#optional arguments, similar to Paolo's 'drive-mirror' command [1], so that the user can request 'absolute-paths' vs. 'relative-paths' as the mode for which of two file names will be written as the backing file at the end of the operation. [1] https://lists.gnu.org/archive/html/qemu-devel/2012-09/msg04592.html --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigC8B70313515BC170BE7A419F 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://www.enigmail.net/ iQEcBAEBCAAGBQJQbyGHAAoJEKeha0olJ0NqEi0IAJWlH34z909YdGMqbkr+GF3f 8DHzs5UDYT6F7uFk5pw0OXk7MT6Iiko9zCInrd/QKoacta5eGkvOtk2oJQzqQ2u2 vXz3PYUAfmWHNErXQfiuRms3wLkVDoezs749psN3GJ+8beXzotWbw3xyyu3YvpB/ nSnJ2Fz4ubSz0e0zSSsxFOHAJjfr/3cl6QDuPm34oNubSPVJQEKoDhv5GiPBI8DY Tliu/hDAO4SvFmDbwojGsCovl+7Bnmm5Ahxf0SpYMQ5jFp9HSMF1wZP9uaB6nAfK I0Mer8VOa642tFdH3PyxAU/7NOo5U1aHtXRkVlYA9VDbCK+1qD0uyZ9tIZ6fSOU= =CNM/ -----END PGP SIGNATURE----- --------------enigC8B70313515BC170BE7A419F--