[Qemu-block] [PATCH 7/7] iotests: Rework 113

This test case has been broken since 398e6ad014df261d (roughly half a year). qemu-img amend requires its output image to be R/W, so it opens it as such; the node is then turned into an read-only node automatically which is now accompanied by a warning, however. This warning has not been part of t

[Qemu-block] [PATCH 4/7] qemu-img: Add print_amend_option_help()

The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help(

[Qemu-block] [PATCH 6/7] iotests: Test help option for unsupporting formats

This adds test cases to 082 for qemu-img create/convert/amend "-o help" on formats that do not support creation or amendment, respectively. Signed-off-by: Max Reitz --- tests/qemu-iotests/082 | 9 + tests/qemu-iotests/082.out | 9 + 2 files changed, 18 insertions(+) diff --g

[Qemu-block] [PATCH 1/7] qemu-img: Amendment support implies create_opts

Instead of checking whether a driver has a non-NULL create_opts we should check whether it supports image amendment in the first place. If it does, it must have create_opts. On the other hand, if it does not have create_opts (so it does not support amendment either), the error message "does not s

[Qemu-block] [PATCH 5/7] qemu-img: Recognize no creation support in -o help

The only users of print_block_option_help() are qemu-img create and qemu-img convert for the output image, so this function is always used for image creation (it used to be used for amendment also, but that is no longer the case). So if image creation is not supported by either the format or the p

[Qemu-block] [PATCH 3/7] qemu-option: Pull out "Supported options" print

It really is up to the caller to decide what this list of options means. Signed-off-by: Max Reitz --- qemu-img.c | 1 + util/qemu-option.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/qemu-img.c b/qemu-img.c index 375fe852e0..6dd8e95bb2 100644 --- a/qemu-img.c +++

[Qemu-block] [PATCH 2/7] block: Add Error parameter to bdrv_amend_options

Looking at the qcow2 code that is riddled with error_report() calls, this is really how it should have been from the start. Signed-off-by: Max Reitz --- include/block/block.h | 3 +- include/block/block_int.h | 3 +- block.c| 8 -- block/qcow2.c | 72

[Qemu-block] [PATCH 0/7] qemu-img: Improve option help for amend

Currently, "qemu-img amend -f $format -o help" prints many things which it claims to be supported, but most of the time it's wrong. Usually that starts with the format already: No format but qcow2 supports option amendment, so we should never claim that a format supports any options when it actual

[Qemu-block] [PATCH v2] qemu-img: Check post-truncation size

Some block drivers (iscsi and file-posix when dealing with device files) do not actually support truncation, even though they provide a .bdrv_truncate() method and will happily return success when providing a new size that does not exceed the current size. This is because these drivers expect the

Re: [Qemu-block] [Qemu-devel] [PATCH] qemu-img: Check post-truncation size

On 2018-04-21 17:35, Eric Blake wrote: > On 04/20/2018 05:53 PM, Max Reitz wrote: >> Some block drivers (iscsi and file-posix when dealing with device files) >> do not actually support truncation, even though they provide a >> .bdrv_truncate() method and will happily return success when providing a

Re: [Qemu-block] [Qemu-devel] [PATCH] qemu-img: Check post-truncation size

On 04/20/2018 05:53 PM, Max Reitz wrote: > Some block drivers (iscsi and file-posix when dealing with device files) > do not actually support truncation, even though they provide a > .bdrv_truncate() method and will happily return success when providing a > new size that does not exceed the current

[Qemu-block] [PATCH v2 8/9] iotests: Copy 197 for COR filter driver

iotest 197 tests copy-on-read using the (now old) copy-on-read flag. Copy it to 215 and modify it to use the COR filter driver instead. Signed-off-by: Max Reitz --- tests/qemu-iotests/215 | 120 + tests/qemu-iotests/215.out | 26 ++ tests/

[Qemu-block] [PATCH v2 5/9] block/quorum: Support BDRV_REQ_WRITE_UNCHANGED

We just need to forward it to quorum's children (except in case of a rewrite because of corruption), but for that we first have to support flags in child requests at all. Signed-off-by: Max Reitz Reviewed-by: Stefan Hajnoczi Reviewed-by: Alberto Garcia --- block/quorum.c | 19 +

[Qemu-block] [PATCH v2 6/9] block: Support BDRV_REQ_WRITE_UNCHANGED in filters

Update the rest of the filter drivers to support BDRV_REQ_WRITE_UNCHANGED. They already forward write request flags to their children, so we just have to announce support for it. This patch does not cover the replication driver because that currently does not support flags at all, and because it

[Qemu-block] [PATCH v2 4/9] block: Set BDRV_REQ_WRITE_UNCHANGED for COR writes

Signed-off-by: Max Reitz Reviewed-by: Stefan Hajnoczi Reviewed-by: Alberto Garcia --- block/io.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/block/io.c b/block/io.c index 134b2a498f..fada4efbf3 100644 --- a/block/io.c +++ b/block/io.c @@ -1115,13 +1115,15 @@ static

[Qemu-block] [PATCH v2 7/9] iotests: Clean up wrap image in 197

Signed-off-by: Max Reitz Reviewed-by: Stefan Hajnoczi Reviewed-by: Alberto Garcia --- tests/qemu-iotests/197 | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/qemu-iotests/197 b/tests/qemu-iotests/197 index 5e869fe2b7..3ae4975eec 100755 --- a/tests/qemu-iotests/197 +++ b/tests/qemu-iote

[Qemu-block] [PATCH v2 3/9] block: Add BDRV_REQ_WRITE_UNCHANGED flag

This flag signifies that a write request will not change the visible disk content. With this flag set, it is sufficient to have the BLK_PERM_WRITE_UNCHANGED permission instead of BLK_PERM_WRITE. Signed-off-by: Max Reitz Reviewed-by: Stefan Hajnoczi Reviewed-by: Alberto Garcia --- include/bloc

[Qemu-block] [PATCH v2 9/9] iotests: Add test for COR across nodes

COR across nodes (that is, you have some filter node between the actually COR target and the node that performs the COR) cannot reliably work together with the permission system when there is no explicit COR node that can request the WRITE_UNCHANGED permission for its child. This is because COR (cu

[Qemu-block] [PATCH v2 0/9] block: Add COR filter driver

This series adds a copy-on-read block filter driver which works by simply setting the BDRV_REQ_COPY_ON_READ flag on write requests (and otherwise just passing everything through). Cover letter of v1: http://lists.nongnu.org/archive/html/qemu-block/2018-04/msg00285.html v2: - Renamed the driver "

[Qemu-block] [PATCH v2 1/9] block: Add COR filter driver

This adds a simple copy-on-read filter driver. It relies on the already existing COR functionality in the central block layer code, which may be moved here once we no longer need it there. Signed-off-by: Max Reitz --- block/Makefile.objs | 2 +- qapi/block-core.json | 5 +- block/copy-on-r

[Qemu-block] [PATCH v2 2/9] block: BLK_PERM_WRITE includes ..._UNCHANGED

Currently we never actually check whether the WRITE_UNCHANGED permission has been taken for unchanging writes. But the one check that is commented out checks both WRITE and WRITE_UNCHANGED; and considering that WRITE_UNCHANGED is already documented as being weaker than WRITE, we should probably ex