Revision tags: v9.2.0, v9.1.2, v9.1.1, v9.1.0 |
|
#
3da71a21 |
| 21-Sep-2023 |
Stefan Hajnoczi <stefanha@redhat.com> |
Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging
Block layer patches
- Graph locking part 4 (node management) - qemu-img map: report compressed data blocks - block-backend: pr
Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging
Block layer patches
- Graph locking part 4 (node management) - qemu-img map: report compressed data blocks - block-backend: process I/O in the current AioContext
# -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmULHnURHGt3b2xmQHJl # ZGhhdC5jb20ACgkQfwmycsiPL9aB5hAAqH8To7WIUtg1rj1PY809ck78ghm18PKg # TNdN7IbrXQghX5foh2VgPwVVl+JaW2CSrJYWQcAO6AbvFduNIi9iKzI6RT0xKXpb # b8oQXS7zntFzwBv8ohOU5NSVJOgVmNP4h5qJIMmXgB9ZcLFG40zggVH2qQT7guUf # 9MAc81kI/d5vvSHY0ZjdHjNOgwG4q1j8yytL7OFqWUfB8sXloUCA9lT7w4jIYD8L # v2StUOLWB01Zts2o8SCNaFxuajs6wUee8b/DM1cyPyLy4KtOdXvLKhq2NlXpLo2i # aZFr4PtizTVwrQZIJttA9jqM+QCsDOsiSat3BLNNsKUaCWHZB0rOGLCzMCtisyOo # 4PzuL4UI21ik2zieO1qVM+Thqvw16kHtp6dD9pGk4X4ogGreGYEIxzBl79luR+AV # NCRizoeFWTHKymS1tSoKrWT9ZNHcLmwemO6Tt1rMYk9jV3T4uY5e1NwxaUavEfsX # f8dLfQjhNiySOoDknT1OSerBOVdTXURS2ri5H3GZxrxvJ4jOeFkn52C8r3YlZ3Wp # Cr9LCUJZeXgwY+Q1JQ3D4VLY8aZ83txpw6XKEy0eTEv5wxkBj5LWhXx7hNb5F3lg # bqaRYijVJn+P82wVxlftIzMfNeVBFHzFE90taPV5grJjr8lgrGBFmD7Puc97kfDX # oTDBwRxJeew= # =qTNA # -----END PGP SIGNATURE----- # gpg: Signature made Wed 20 Sep 2023 12:31:49 EDT # gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6 # gpg: issuer "kwolf@redhat.com" # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* tag 'for-upstream' of https://repo.or.cz/qemu/kevin: (28 commits) block: mark aio_poll as non-coroutine block-backend: process zoned requests in the current AioContext block-backend: process I/O in the current AioContext test-bdrv-drain: avoid race with BH in IOThread drain test block: remove AIOCBInfo->get_aio_context() qemu-img: map: report compressed data blocks block: add BDRV_BLOCK_COMPRESSED flag for bdrv_block_status() block: Mark bdrv_add/del_child() and caller GRAPH_WRLOCK block: Mark bdrv_unref_child() GRAPH_WRLOCK block: Mark bdrv_root_unref_child() GRAPH_WRLOCK block: Take graph rdlock in bdrv_change_aio_context() block: Take graph rdlock in bdrv_drop_intermediate() block: Mark bdrv_parent_cb_change_media() GRAPH_RDLOCK block: Mark bdrv_child_perm() GRAPH_RDLOCK block: Mark bdrv_get_cumulative_perm() and callers GRAPH_RDLOCK block: Mark bdrv_parent_perms_conflict() and callers GRAPH_RDLOCK block: Mark bdrv_attach_child() GRAPH_WRLOCK block: Call transaction callbacks with lock held block: Mark bdrv_attach_child_common() GRAPH_WRLOCK block: Mark bdrv_replace_child_tran() GRAPH_WRLOCK ...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
show more ...
|
#
52b10c9c |
| 07-Sep-2023 |
Andrey Drobyshev via <qemu-block@nongnu.org> |
qemu-img: map: report compressed data blocks
Right now "qemu-img map" reports compressed blocks as containing data but having no host offset. This is not very informative. Instead, let's add anoth
qemu-img: map: report compressed data blocks
Right now "qemu-img map" reports compressed blocks as containing data but having no host offset. This is not very informative. Instead, let's add another boolean field named "compressed" in case JSON output mode is specified. This is achieved by utilizing new allocation status flag BDRV_BLOCK_COMPRESSED for bdrv_block_status().
Also update the expected qemu-iotests outputs to contain the new field.
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Message-ID: <20230907210226.953821-3-andrey.drobyshev@virtuozzo.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
Revision tags: v8.0.0, v7.2.0, v7.0.0, v6.2.0, v6.1.0 |
|
#
708f5019 |
| 13-Jul-2021 |
Peter Maydell <peter.maydell@linaro.org> |
Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2021-07-09-v2' into staging
nbd patches for 2021-07-09
- enhance 'qemu-img map --output=json' to make it easier to duplicate backing chain
Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2021-07-09-v2' into staging
nbd patches for 2021-07-09
- enhance 'qemu-img map --output=json' to make it easier to duplicate backing chain allocation patterns - fix a race in the 'yank' QMP command in relation to NBD requests
# gpg: Signature made Mon 12 Jul 2021 18:43:37 BST # gpg: using RSA key 71C2CC22B1C4602927D2F3AAA7A16B4A2527436A # gpg: Good signature from "Eric Blake <eblake@redhat.com>" [full] # gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>" [full] # gpg: aka "[jpeg image of size 6874]" [full] # Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A
* remotes/ericb/tags/pull-nbd-2021-07-09-v2: nbd: register yank function earlier qemu-img: Reword 'qemu-img map --output=json' docs qemu-img: Make unallocated part of backing chain obvious in map iotests: Improve and rename test 309 to nbd-qemu-allocation
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
#
8417e137 |
| 01-Jul-2021 |
Eric Blake <eblake@redhat.com> |
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 spars
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>
show more ...
|
Revision tags: v5.2.0, v5.0.0, v4.2.0 |
|
#
6b422e5f |
| 04-Sep-2019 |
Peter Maydell <peter.maydell@linaro.org> |
Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-09-03' into staging
Block patches: - qemu-io now accepts a file to read a write pattern from - Ensure that raw files have their fi
Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-09-03' into staging
Block patches: - qemu-io now accepts a file to read a write pattern from - Ensure that raw files have their first block allocated so we can probe the O_DIRECT alignment if necessary - Various fixes
# gpg: Signature made Tue 03 Sep 2019 13:58:57 BST # gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40 # gpg: issuer "mreitz@redhat.com" # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full] # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40
* remotes/maxreitz/tags/pull-block-2019-09-03: iotests: Unify cache mode quoting tests/check-block: Skip iotests when sanitizers are enabled iotests: Check for enabled drivers before testing them iotests: Add -display none to the qemu options file-posix: fix request_alignment typo iotests: Disable 126 for flat vmdk subformats iotests: Disable 110 for vmdk.twoGbMaxExtentSparse iotests: Disable broken streamOptimized tests vmdk: Reject invalid compressed writes iotests: Keep testing broken relative extent paths vmdk: Use bdrv_dirname() for relative extent paths iotests: Fix _filter_img_create() iotests: Test allocate_first_block() with O_DIRECT block: posix: Always allocate the first block block: fix permission update in bdrv_replace_node qemu-io: add pattern file for write command
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
#
3a20013f |
| 26-Aug-2019 |
Nir Soffer <nirsof@gmail.com> |
block: posix: Always allocate the first block
When creating an image with preallocation "off" or "falloc", the first block of the image is typically not allocated. When using Gluster storage backed
block: posix: Always allocate the first block
When creating an image with preallocation "off" or "falloc", the first block of the image is typically not allocated. When using Gluster storage backed by XFS filesystem, reading this block using direct I/O succeeds regardless of request length, fooling alignment detection.
In this case we fallback to a safe value (4096) instead of the optimal value (512), which may lead to unneeded data copying when aligning requests. Allocating the first block avoids the fallback.
Since we allocate the first block even with preallocation=off, we no longer create images with zero disk size:
$ ./qemu-img create -f raw test.raw 1g Formatting 'test.raw', fmt=raw size=1073741824
$ ls -lhs test.raw 4.0K -rw-r--r--. 1 nsoffer nsoffer 1.0G Aug 16 23:48 test.raw
And converting the image requires additional cluster:
$ ./qemu-img measure -f raw -O qcow2 test.raw required size: 458752 fully allocated size: 1074135040
When using format like vmdk with multiple files per image, we allocate one block per file:
$ ./qemu-img create -f vmdk -o subformat=twoGbMaxExtentFlat test.vmdk 4g Formatting 'test.vmdk', fmt=vmdk size=4294967296 compat6=off hwversion=undefined subformat=twoGbMaxExtentFlat
$ ls -lhs test*.vmdk 4.0K -rw-r--r--. 1 nsoffer nsoffer 2.0G Aug 27 03:23 test-f001.vmdk 4.0K -rw-r--r--. 1 nsoffer nsoffer 2.0G Aug 27 03:23 test-f002.vmdk 4.0K -rw-r--r--. 1 nsoffer nsoffer 353 Aug 27 03:23 test.vmdk
I did quick performance test for copying disks with qemu-img convert to new raw target image to Gluster storage with sector size of 512 bytes:
for i in $(seq 10); do rm -f dst.raw sleep 10 time ./qemu-img convert -f raw -O raw -t none -T none src.raw dst.raw done
Here is a table comparing the total time spent:
Type Before(s) After(s) Diff(%) --------------------------------------- real 530.028 469.123 -11.4 user 17.204 10.768 -37.4 sys 17.881 7.011 -60.7
We can see very clear improvement in CPU usage.
Signed-off-by: Nir Soffer <nsoffer@redhat.com> Message-id: 20190827010528.8818-2-nsoffer@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
show more ...
|
#
2259637b |
| 20-May-2019 |
Peter Maydell <peter.maydell@linaro.org> |
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
Block layer patches:
- block: AioContext management, part 1 - qmp: forbid qmp_cont in RUN_STATE_FINISH_MIGRATE - nvme: fi
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
Block layer patches:
- block: AioContext management, part 1 - qmp: forbid qmp_cont in RUN_STATE_FINISH_MIGRATE - nvme: fix copy direction in DMA reads going to CMB - file-posix: Fix block status for unaligned raw images with O_DIRECT - file-posix: Fix xfs_write_zeroes() after EOF - Documentation and iotests improvements
# gpg: Signature made Mon 20 May 2019 16:12:38 BST # gpg: using RSA key 7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* remotes/kevin/tags/for-upstream: (24 commits) iotests: Make 245 faster and more reliable iotests.py: Fix VM.run_job iotests.py: Let assert_qmp() accept an array block: Improve "Block node is read-only" message qemu-img.texi: Describe human-readable info output qemu-img.texi: Be specific about JSON object types iotests: Test unaligned raw images with O_DIRECT block/file-posix: Unaligned O_DIRECT block-status test-block-iothread: Test AioContext propagation for block jobs blockjob: Remove AioContext notifiers blockjob: Propagate AioContext change to all job nodes block: Add blk_set_allow_aio_context_change() block: Implement .(can_)set_aio_ctx for BlockBackend test-block-iothread: Test AioContext propagation through the tree block: Propagate AioContext change to parents block: Move recursion to bdrv_set_aio_context() block: Make bdrv_attach/detach_aio_context() static block: Add bdrv_try_set_aio_context() nvme: fix copy direction in DMA reads going to CMB iotest: fix 169: do not run qmp_cont in RUN_STATE_FINISH_MIGRATE ...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
#
2fab30c8 |
| 14-May-2019 |
Max Reitz <mreitz@redhat.com> |
iotests: Test unaligned raw images with O_DIRECT
We already have 221 for accesses through the page cache, but it is better to create a new file for O_DIRECT instead of integrating those test cases i
iotests: Test unaligned raw images with O_DIRECT
We already have 221 for accesses through the page cache, but it is better to create a new file for O_DIRECT instead of integrating those test cases into 221. This way, we can make use of _supported_cache_modes (and _default_cache_mode) so the test is automatically skipped on filesystems that do not support O_DIRECT.
As part of the split, add _supported_cache_modes to 221. With that, it no longer fails when run with -c none or -c directsync.
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|