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

[Max Reitz]

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 <address@hidden>
> > ---
> > 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 <address@hidden>

Thanks!

Max