From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhMP5-0006Nz-F7 for qemu-devel@nongnu.org; Thu, 23 Oct 2014 13:42:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhMP0-0006id-Cr for qemu-devel@nongnu.org; Thu, 23 Oct 2014 13:42:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhMOz-0006hb-PG for qemu-devel@nongnu.org; Thu, 23 Oct 2014 13:42:21 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NHgJMs003108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Oct 2014 13:42:20 -0400 Message-ID: <54493DFA.6070004@redhat.com> Date: Thu, 23 Oct 2014 11:42:18 -0600 From: Eric Blake MIME-Version: 1.0 References: <1414076175-17034-1-git-send-email-mreitz@redhat.com> <1414076175-17034-2-git-send-email-mreitz@redhat.com> In-Reply-To: <1414076175-17034-2-git-send-email-mreitz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WFu0Pe0EPNsQxOemcTBuKwKb6oCwFsIPI" Subject: Re: [Qemu-devel] [PATCH 1/2] block: JSON filenames and relative backing files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WFu0Pe0EPNsQxOemcTBuKwKb6oCwFsIPI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/23/2014 08:56 AM, Max Reitz wrote: > When using a relative backing file name, qemu needs to know the > directory of the top image file. For JSON filenames, such a directory > cannot be easily determined (e.g. how do you determine the directory of= > a qcow2 BDS directly on top of a quorum BDS?). Therefore, do not allow > relative filenames for the backing file of BDSs only having a JSON > filename. >=20 Are JSON names the only case where we want to do this, or should we widen it to all non-file protocol names? Then again, the use of relative names is currently being used as a NICE way on glusterfs setups to hide whether two files are both being accessed via gluster protocol or both being accessed via file protocol (if the gluster volume is also mapped to the local file system such as via NFS) - that is, referring to 'base.img' as the backing file of 'top.img' works whether you opened '/path/to/top.img' or 'gluster://host/volume/path/to/top.img', when base.img and top.img are in the same directory of the gluster volume. > Signed-off-by: Max Reitz > --- > Just by the way, the reason for using bs->exact_filename in > bdrv_get_full_backing_filename() instead of just testing whether > bs->filename is prefixed by "json:" is that in the future we might have= > cases where bs->filename contains a JSON filename, but > bs->exact_filename is set to a non-JSON filename (because there are som= e > rather vital options, which radically change performance or something > like that, so we want them to be included in bs->filename if they were > specified; but we can still generate a plain filename which results in > the same data read and written, but just in some very different way or > something like that). > Actually, I might write a follow-up patch which makes > bdrv_refresh_filename() always generate an exact_filename if somehow > possible, even if unknown options were specified. This would then be > very useful for this function, but on the other hand, it would no longe= r > fit the definition of exact_filename (in order to follow that > definition, we have to be certain that we don't omit any vital options > which really change the data read and written). > --- > block.c | 19 +++++++++++++++---- > block/qapi.c | 7 ++++++- > include/block/block.h | 2 +- > 3 files changed, 22 insertions(+), 6 deletions(-) >=20 Reviewed-by: Eric Blake --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --WFu0Pe0EPNsQxOemcTBuKwKb6oCwFsIPI 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 iQEcBAEBCAAGBQJUST36AAoJEKeha0olJ0NqoBAH/2vs3rbJkJN6VGBSar55qLCy wQBCoY5Ehurtetc5zOFIrDGqtYrFNfU6Pc19LF2+ZybQ6fg1Y6Sdy8Q14IX8uAzf 91pwSA2c55dMoGuKCH0aJuQsDHZSiiwCt7a+e5hYFSvxUV5PwqKzz3Lbw8Qhzs29 djzYPZtw1bCU1Cb0GncploUVWxML3vxdmTD2O8gXTXMWfnCZ8alCI1pO6awMeKBo u/3gGUqXHk3HhnKPDZ9V2PPRDCTVAQ0zQz4DKjCXeZkrBT22IH/5BzcsEWPFGvbt BMu/n/dPR4FZsS03kzmB+HcJSeN9QWhFr53qZ7QcGH5FqmmsrIJCF+4lXlC/ksI= =L2Ey -----END PGP SIGNATURE----- --WFu0Pe0EPNsQxOemcTBuKwKb6oCwFsIPI--