Re: [Qemu-devel] [PATCH 1/2] block: JSON filenames and relative backing files

[Max Reitz <mreitz@redhat.com>]

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 <mreitz@redhat.com>
>> ---
>> 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 <eblake@redhat.com>

Thanks!

Max