On 26.10.2015 19:12, John Snow wrote: > For more complex BDS trees that can be created under normal circumstances, > we lose the ability to issue query commands because of our inability to > re-construct the absolute filename. > > Instead, omit this field when it is a problem and present as much information > as we can. > > This will change the expected output in iotest 110, where we will now see a > json filename and the lack of an absolute filename instead of an error. > > Signed-off-by: John Snow <[email protected]> > --- > block/qapi.c | 10 ++++++---- > tests/qemu-iotests/110.out | 5 ++++- > 2 files changed, 10 insertions(+), 5 deletions(-)
One problem I see now is that qemu-img --backing-chain uses the full
backing name if it is available and if it isn't, it resorts to the
non-full backing name (which was good until this patch, as far as I can
see). But now that's not necessarily a valid substitution anymore:
$ mkdir foo
$ ./qemu-img create -f qcow2 foo/base.qcow2 64M
$ ./qemu-img create -f qcow2 -b base.qcow2 foo/top.qcow2
$ ./qemu-img create -f qcow2 base.qcow2 64M
$ ./qemu-img info --backing-chain foo/top.qcow2
image: foo/top.qcow2
file format: qcow2
virtual size: 64M (67108864 bytes)
disk size: 196K
cluster_size: 65536
backing file: base.qcow2 (actual path: foo/base.qcow2)
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
image: foo/base.qcow2
file format: qcow2
virtual size: 64M (67108864 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
$ ./qemu-img info --backing-chain \
"json:{'file.filename':'foo/top.qcow2',
'driver':'qcow2','lazy-refcounts':true}"
image: json:{"lazy-refcounts": true, "driver": "qcow2", "file":
{"driver": "file", "filename": "foo/top.qcow2"}}
file format: qcow2
virtual size: 64M (67108864 bytes)
disk size: 196K
cluster_size: 65536
backing file: base.qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
image: base.qcow2
file format: qcow2
virtual size: 32M (33554432 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
As you can see, in the second case, the wrong base.qcow2 was used. I
think qemu-img info --backing-chain should abort once it hits a point
where has_full_backing_filename is false; but for that to work, we need
to set info->full_backing_filename even if the "relative" and the
absolute backing filename (backing_filename and backing_filename2) are
equal.
(By the way: It's actually some kind of a bug that you can open images
with JSON filenames and backing files; this only works because
bdrv_open_backing_file() is called before bdrv_refresh_filename().
Actually, after my "Drop BDS.filename" series it will no longer work.
This is bad. I need to fix this before I can continue the series...)
((It is bad because that means:
$ x86_64-softmmu/qemu-system-x86_64 \
-drive if=none,file.filename=foo/top.qcow2,lazy-refcounts=on
qemu-system-x86_64: -drive
if=none,file.filename=foo/top.qcow2,lazy-refcounts=on: Cannot use
relative backing file names for 'json:{"lazy-refcounts": "on", "driver":
"qcow2", "file": {"driver": "file", "filename": "foo/top.qcow2"}}'
And that's bad.))
(((So for this patch that means I guess we should just fix
bdrv_get_full_backing_filename() instead.)))
Max
signature.asc
Description: OpenPGP digital signature
