From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhMh9-0001Ai-Ag for qemu-devel@nongnu.org; Thu, 23 Oct 2014 14:01:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhMh3-000587-4P for qemu-devel@nongnu.org; Thu, 23 Oct 2014 14:01:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhMh2-000583-Tb for qemu-devel@nongnu.org; Thu, 23 Oct 2014 14:01:01 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NI0xOF011464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Oct 2014 14:01:00 -0400 Message-ID: <54494258.9050801@redhat.com> Date: Thu, 23 Oct 2014 20:00:56 +0200 From: Max Reitz MIME-Version: 1.0 References: <1414076175-17034-1-git-send-email-mreitz@redhat.com> <1414076175-17034-2-git-send-email-mreitz@redhat.com> <54493DFA.6070004@redhat.com> In-Reply-To: <54493DFA.6070004@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi On 23.10.2014 19:42, Eric Blake wrote: > 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. >> > Are JSON names the only case where we want to do this, or should we > widen it to all non-file protocol names? It'll probably work for HTTP, NFS of course and I can see it working for NBD, too, if one is crazy enough to do that (and you're mentioning glusterfs). In general, I think all filenames have some normal unix-path-like sequence as their tail, so relative filenames can work there (and maybe there are even people using it already for all kinds of non-file protocols). > 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 some >> 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 longer >> 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(-) >> > Reviewed-by: Eric Blake Thanks! Max