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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

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?  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>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]