2019-02-22 11:45:50 +01:00
|
|
|
QA output created by 244
|
|
|
|
|
|
|
|
|
|
=== Create and open image with external data file ===
|
|
|
|
|
|
|
|
|
|
With data file name in the image:
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 data_file=TEST_DIR/t.IMGFMT.data
|
|
|
|
|
No errors were found on the image.
|
|
|
|
|
read 65536/65536 bytes at offset 0
|
|
|
|
|
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 65536/65536 bytes at offset 0
|
|
|
|
|
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Could not open 'inexistent': No such file or directory
|
2019-02-22 11:45:50 +01:00
|
|
|
no file open, try 'help open'
|
|
|
|
|
|
|
|
|
|
Data file required, but without data file name in the image:
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: 'data-file' is required for this image
|
2019-02-22 11:45:50 +01:00
|
|
|
no file open, try 'help open'
|
|
|
|
|
read 65536/65536 bytes at offset 0
|
|
|
|
|
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Could not open 'inexistent': No such file or directory
|
2019-02-22 11:45:50 +01:00
|
|
|
no file open, try 'help open'
|
|
|
|
|
|
|
|
|
|
Setting data-file for an image with internal data:
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: 'data-file' can only be set for images with an external data file
|
2019-02-22 11:45:50 +01:00
|
|
|
no file open, try 'help open'
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Could not open 'inexistent': No such file or directory
|
2019-02-22 11:45:50 +01:00
|
|
|
no file open, try 'help open'
|
|
|
|
|
|
|
|
|
|
=== Conflicting features ===
|
|
|
|
|
|
|
|
|
|
Convert to compressed target with data file:
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT.src', fmt=IMGFMT size=67108864
|
|
|
|
|
wrote 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
2020-04-02 15:57:17 +02:00
|
|
|
qemu-img: error while writing at byte 0: Operation not supported
|
2019-02-22 11:45:50 +01:00
|
|
|
|
|
|
|
|
Convert uncompressed, then write compressed data manually:
|
|
|
|
|
Images are identical.
|
|
|
|
|
write failed: Operation not supported
|
|
|
|
|
No errors were found on the image.
|
|
|
|
|
|
|
|
|
|
Take an internal snapshot:
|
|
|
|
|
qemu-img: Could not create snapshot 'test': -95 (Operation not supported)
|
|
|
|
|
No errors were found on the image.
|
|
|
|
|
|
|
|
|
|
=== Standalone image with external data file (efficient) ===
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 data_file=TEST_DIR/t.IMGFMT.data
|
|
|
|
|
qcow2 file size before I/O: 196616
|
|
|
|
|
|
|
|
|
|
wrote 4194304/4194304 bytes at offset 1048576
|
|
|
|
|
4 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
discard 2097152/2097152 bytes at offset 2097152
|
|
|
|
|
2 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 3145728/3145728 bytes at offset 3145728
|
|
|
|
|
3 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
No errors were found on the image.
|
|
|
|
|
|
qemu-img: Make unallocated part of backing chain obvious in map
The recently-added NBD context qemu:allocation-depth is able to
distinguish between locally-present data (even when that data is
sparse) [shown as depth 1 over NBD], and data that could not be found
anywhere in the backing chain [shown as depth 0]; and the libnbd
project was recently patched to give the human-readable name "absent"
to an allocation-depth of 0. But qemu-img map --output=json predates
that addition, and has the unfortunate behavior that all portions of
the backing chain that resolve without finding a hit in any backing
layer report the same depth as the final backing layer. This makes it
harder to reconstruct a qcow2 backing chain using just 'qemu-img map'
output, especially when using "backing":null to artificially limit a
backing chain, because it is impossible to distinguish between a
QCOW2_CLUSTER_UNALLOCATED (which defers to a [missing] backing file)
and a QCOW2_CLUSTER_ZERO_PLAIN cluster (which would override any
backing file), since both types of clusters otherwise show as
"data":false,"zero":true" (but note that we can distinguish a
QCOW2_CLUSTER_ZERO_ALLOCATED, which would also have an "offset":
listing).
The task of reconstructing a qcow2 chain was made harder in commit
0da9856851 (nbd: server: Report holes for raw images), because prior
to that point, it was possible to abuse NBD's block status command to
see which portions of a qcow2 file resulted in BDRV_BLOCK_ALLOCATED
(showing up as NBD_STATE_ZERO in isolation) vs. missing from the chain
(showing up as NBD_STATE_ZERO|NBD_STATE_HOLE); but now qemu reports
more accurate sparseness information over NBD.
An obvious solution is to make 'qemu-img map --output=json' add an
additional "present":false designation to any cluster lacking an
allocation anywhere in the chain, without any change to the "depth"
parameter to avoid breaking existing clients. The iotests have
several examples where this distinction demonstrates the additional
accuracy.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210701190655.2131223-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
[eblake: fix more iotest fallout]
Signed-off-by: Eric Blake <eblake@redhat.com>
2021-07-01 21:06:55 +02:00
|
|
|
[{ "start": 0, "length": 1048576, "depth": 0, "present": false, "zero": true, "data": false},
|
|
|
|
|
{ "start": 1048576, "length": 1048576, "depth": 0, "present": true, "zero": false, "data": true, "offset": 1048576},
|
|
|
|
|
{ "start": 2097152, "length": 2097152, "depth": 0, "present": true, "zero": true, "data": false},
|
|
|
|
|
{ "start": 4194304, "length": 1048576, "depth": 0, "present": true, "zero": true, "data": false, "offset": 4194304},
|
|
|
|
|
{ "start": 5242880, "length": 1048576, "depth": 0, "present": true, "zero": true, "data": false},
|
|
|
|
|
{ "start": 6291456, "length": 60817408, "depth": 0, "present": false, "zero": true, "data": false}]
|
2019-02-22 11:45:50 +01:00
|
|
|
|
|
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 1048576
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 4194304/4194304 bytes at offset 2097152
|
|
|
|
|
4 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
|
|
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 1048576
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 4194304
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 5242880
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
qcow2 file size after I/O: 327680
|
|
|
|
|
|
|
|
|
|
=== Standalone image with external data file (valid raw) ===
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 data_file=TEST_DIR/t.IMGFMT.data data_file_raw=on
|
2021-03-26 15:55:08 +01:00
|
|
|
qcow2 file size before I/O: 327680
|
2019-02-22 11:45:50 +01:00
|
|
|
|
|
|
|
|
wrote 4194304/4194304 bytes at offset 1048576
|
|
|
|
|
4 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
discard 2097152/2097152 bytes at offset 2097152
|
|
|
|
|
2 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
wrote 3145728/3145728 bytes at offset 3145728
|
|
|
|
|
3 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
No errors were found on the image.
|
|
|
|
|
|
qemu-img: Make unallocated part of backing chain obvious in map
The recently-added NBD context qemu:allocation-depth is able to
distinguish between locally-present data (even when that data is
sparse) [shown as depth 1 over NBD], and data that could not be found
anywhere in the backing chain [shown as depth 0]; and the libnbd
project was recently patched to give the human-readable name "absent"
to an allocation-depth of 0. But qemu-img map --output=json predates
that addition, and has the unfortunate behavior that all portions of
the backing chain that resolve without finding a hit in any backing
layer report the same depth as the final backing layer. This makes it
harder to reconstruct a qcow2 backing chain using just 'qemu-img map'
output, especially when using "backing":null to artificially limit a
backing chain, because it is impossible to distinguish between a
QCOW2_CLUSTER_UNALLOCATED (which defers to a [missing] backing file)
and a QCOW2_CLUSTER_ZERO_PLAIN cluster (which would override any
backing file), since both types of clusters otherwise show as
"data":false,"zero":true" (but note that we can distinguish a
QCOW2_CLUSTER_ZERO_ALLOCATED, which would also have an "offset":
listing).
The task of reconstructing a qcow2 chain was made harder in commit
0da9856851 (nbd: server: Report holes for raw images), because prior
to that point, it was possible to abuse NBD's block status command to
see which portions of a qcow2 file resulted in BDRV_BLOCK_ALLOCATED
(showing up as NBD_STATE_ZERO in isolation) vs. missing from the chain
(showing up as NBD_STATE_ZERO|NBD_STATE_HOLE); but now qemu reports
more accurate sparseness information over NBD.
An obvious solution is to make 'qemu-img map --output=json' add an
additional "present":false designation to any cluster lacking an
allocation anywhere in the chain, without any change to the "depth"
parameter to avoid breaking existing clients. The iotests have
several examples where this distinction demonstrates the additional
accuracy.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210701190655.2131223-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
[eblake: fix more iotest fallout]
Signed-off-by: Eric Blake <eblake@redhat.com>
2021-07-01 21:06:55 +02:00
|
|
|
[{ "start": 0, "length": 2097152, "depth": 0, "present": true, "zero": false, "data": true, "offset": 0},
|
|
|
|
|
{ "start": 2097152, "length": 2097152, "depth": 0, "present": true, "zero": true, "data": false},
|
|
|
|
|
{ "start": 4194304, "length": 2097152, "depth": 0, "present": true, "zero": true, "data": false, "offset": 4194304},
|
|
|
|
|
{ "start": 6291456, "length": 60817408, "depth": 0, "present": true, "zero": false, "data": true, "offset": 6291456}]
|
2019-02-22 11:45:50 +01:00
|
|
|
|
|
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 1048576
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 4194304/4194304 bytes at offset 2097152
|
|
|
|
|
4 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
|
2020-04-09 21:10:06 +02:00
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 1048576
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 3145728/3145728 bytes at offset 3145728
|
|
|
|
|
3 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
2019-02-22 11:45:50 +01:00
|
|
|
qcow2 file size after I/O: 327680
|
|
|
|
|
|
|
|
|
|
=== bdrv_co_block_status test for file and offset=0 ===
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 data_file=TEST_DIR/t.IMGFMT.data
|
|
|
|
|
wrote 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
Offset Length Mapped to File
|
|
|
|
|
0 0x100000 0 TEST_DIR/t.qcow2.data
|
qemu-img: Make unallocated part of backing chain obvious in map
The recently-added NBD context qemu:allocation-depth is able to
distinguish between locally-present data (even when that data is
sparse) [shown as depth 1 over NBD], and data that could not be found
anywhere in the backing chain [shown as depth 0]; and the libnbd
project was recently patched to give the human-readable name "absent"
to an allocation-depth of 0. But qemu-img map --output=json predates
that addition, and has the unfortunate behavior that all portions of
the backing chain that resolve without finding a hit in any backing
layer report the same depth as the final backing layer. This makes it
harder to reconstruct a qcow2 backing chain using just 'qemu-img map'
output, especially when using "backing":null to artificially limit a
backing chain, because it is impossible to distinguish between a
QCOW2_CLUSTER_UNALLOCATED (which defers to a [missing] backing file)
and a QCOW2_CLUSTER_ZERO_PLAIN cluster (which would override any
backing file), since both types of clusters otherwise show as
"data":false,"zero":true" (but note that we can distinguish a
QCOW2_CLUSTER_ZERO_ALLOCATED, which would also have an "offset":
listing).
The task of reconstructing a qcow2 chain was made harder in commit
0da9856851 (nbd: server: Report holes for raw images), because prior
to that point, it was possible to abuse NBD's block status command to
see which portions of a qcow2 file resulted in BDRV_BLOCK_ALLOCATED
(showing up as NBD_STATE_ZERO in isolation) vs. missing from the chain
(showing up as NBD_STATE_ZERO|NBD_STATE_HOLE); but now qemu reports
more accurate sparseness information over NBD.
An obvious solution is to make 'qemu-img map --output=json' add an
additional "present":false designation to any cluster lacking an
allocation anywhere in the chain, without any change to the "depth"
parameter to avoid breaking existing clients. The iotests have
several examples where this distinction demonstrates the additional
accuracy.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210701190655.2131223-3-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
[eblake: fix more iotest fallout]
Signed-off-by: Eric Blake <eblake@redhat.com>
2021-07-01 21:06:55 +02:00
|
|
|
[{ "start": 0, "length": 1048576, "depth": 0, "present": true, "zero": false, "data": true, "offset": 0},
|
|
|
|
|
{ "start": 1048576, "length": 66060288, "depth": 0, "present": false, "zero": true, "data": false}]
|
2020-02-11 10:49:00 +01:00
|
|
|
|
|
|
|
|
=== Copy offloading ===
|
|
|
|
|
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 data_file=TEST_DIR/t.IMGFMT.data
|
|
|
|
|
Images are identical.
|
|
|
|
|
Images are identical.
|
2019-11-13 17:26:07 +01:00
|
|
|
|
|
|
|
|
=== Flushing should flush the data file ===
|
|
|
|
|
|
|
|
|
|
wrote 512/512 bytes at offset 0
|
|
|
|
|
512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
|
|
|
|
|
Success: qemu-io failed, so the data file was flushed
|
2021-03-26 15:55:09 +01:00
|
|
|
|
|
|
|
|
=== Preallocation with data-file-raw ===
|
|
|
|
|
|
|
|
|
|
--- Using a non-zeroed data file ---
|
|
|
|
|
wrote 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
{ "execute": "qmp_capabilities" }
|
|
|
|
|
{"return": {}}
|
|
|
|
|
{ "execute": "blockdev-create",
|
|
|
|
|
"arguments": {
|
|
|
|
|
"job-id": "create",
|
|
|
|
|
"options": {
|
|
|
|
|
"driver": "IMGFMT",
|
|
|
|
|
"size": 1048576,
|
|
|
|
|
"file": "meta",
|
|
|
|
|
"data-file": "data",
|
|
|
|
|
"data-file-raw": true
|
|
|
|
|
} } }
|
|
|
|
|
{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "create"}}
|
|
|
|
|
{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "create"}}
|
|
|
|
|
{"return": {}}
|
|
|
|
|
{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "create"}}
|
|
|
|
|
{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "create"}}
|
|
|
|
|
{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "create"}}
|
|
|
|
|
{ "execute": "job-dismiss", "arguments": { "id": "create" } }
|
|
|
|
|
{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "create"}}
|
|
|
|
|
{"return": {}}
|
|
|
|
|
|
|
|
|
|
Comparing pattern:
|
|
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
Images are identical.
|
|
|
|
|
|
|
|
|
|
--- Truncation (growing) ---
|
|
|
|
|
wrote 1048576/1048576 bytes at offset 1048576
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
Image resized.
|
|
|
|
|
|
|
|
|
|
Comparing pattern:
|
|
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 1048576
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
read 1048576/1048576 bytes at offset 1048576
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
Images are identical.
|
|
|
|
|
|
|
|
|
|
--- Giving a backing file at runtime ---
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 data_file=TEST_DIR/t.IMGFMT.data data_file_raw=on
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=1048576
|
|
|
|
|
wrote 1048576/1048576 bytes at offset 0
|
|
|
|
|
1 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
|
|
|
|
|
|
|
|
|
|
Comparing qcow2 image and raw data file:
|
|
|
|
|
Images are identical.
|
2019-02-22 11:45:50 +01:00
|
|
|
*** done
|
