Re: [Qemu-block] [Qemu-devel] [PATCH for-2.9] block: Drop unmaintained 'archipelago' driver

On Wed, 03/08 21:18, Max Reitz wrote: > On 08.03.2017 21:09, Eric Blake wrote: > > On 03/08/2017 02:05 PM, Max Reitz wrote: > >> On 08.03.2017 21:02, Eric Blake wrote: > >>> The driver has failed to build since commit da34e65, in qemu 2.6, > >>> due to a missing include of qapi/error.h for

Re: [Qemu-block] [Qemu-devel] [PATCH RFC 1/1] vmstate: draft fix for failed iotests case 68 and 91

在 2017/3/8 19:33, Halil Pasic 写道: On 03/08/2017 08:05 AM, QingFeng Hao wrote: 在 2017/3/7 18:19, Halil Pasic 写道: On 03/07/2017 11:05 AM, Kevin Wolf wrote: Am 07.03.2017 um 10:54 hat Halil Pasic geschrieben: On 03/07/2017 10:29 AM, Kevin Wolf wrote: Am 07.03.2017 um 03:53 hat QingFeng Hao

[Qemu-block] [PATCH 3/3] migration: Document handling of bdrv_is_allocated() errors

Migration is the only code left in the tree that does not react to bdrv_is_allocated() failures. But as there is no useful way to react to the failure, and we are merely skipping unallocated sectors on success, just document that our choice of handling is intended. Signed-off-by: Eric Blake

[Qemu-block] [PATCH 1/3] backup: React to bdrv_is_allocated() errors

If bdrv_is_allocated() fails, we should immediately do the backup error action, rather than attempting backup_do_cow() (although that will likely fail too). Signed-off-by: Eric Blake --- block/backup.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-)

[Qemu-block] [PATCH 2/3] vvfat: React to bdrv_is_allocated() errors

If bdrv_is_allocated() fails, we should react to that failure. For 2 of the 3 callers, reporting the error was easy. But in cluster_was_modified() and its lone caller get_cluster_count_for_direntry(), it's rather invasive to update the logic to pass the error back; so there, I went with merely

[Qemu-block] [PATCH for-2.9 0/3] Fix bdrv_is_allocated usage bugs

bdrv_is_allocated() returns tri-state, not just bool, although there were several callers using it as a bool. Fix them to either propagate the error or to document why treatment of failure like allocation is okay. [Found during a larger effort to convert bdrv_get_block_status to be byte-based

Re: [Qemu-block] [PATCH for-2.9] block: Drop unmaintained 'archipelago' driver

On 08.03.2017 21:09, Eric Blake wrote: > On 03/08/2017 02:05 PM, Max Reitz wrote: >> On 08.03.2017 21:02, Eric Blake wrote: >>> The driver has failed to build since commit da34e65, in qemu 2.6, >>> due to a missing include of qapi/error.h for error_setg(). >>> Since no one has complained in three

Re: [Qemu-block] [PATCH for-2.9] block: Drop unmaintained 'archipelago' driver

On 03/08/2017 02:05 PM, Max Reitz wrote: > On 08.03.2017 21:02, Eric Blake wrote: >> The driver has failed to build since commit da34e65, in qemu 2.6, >> due to a missing include of qapi/error.h for error_setg(). >> Since no one has complained in three releases, it is easier to >> remove the dead

Re: [Qemu-block] [PATCH for-2.9] block: Drop unmaintained 'archipelago' driver

On 08.03.2017 21:02, Eric Blake wrote: > The driver has failed to build since commit da34e65, in qemu 2.6, > due to a missing include of qapi/error.h for error_setg(). > Since no one has complained in three releases, it is easier to > remove the dead code than to keep it around, especially since

[Qemu-block] [PATCH for-2.9] block: Drop unmaintained 'archipelago' driver

The driver has failed to build since commit da34e65, in qemu 2.6, due to a missing include of qapi/error.h for error_setg(). Since no one has complained in three releases, it is easier to remove the dead code than to keep it around, especially since it is not being built by default and therefore

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.9] block/archipelago: Make it compile

On 03/08/2017 12:46 PM, Kevin Wolf wrote: >>> Oh, I meant to add: >>> >>> Should probably mention that it was commit da34e65 that introduced the >>> problem (if I'm right?). Does that mean we have not been compiling >>> archipelago.c since Mar 2016? >> >> At least here on my machine it does

[Qemu-block] [PATCH v2 for-2.10 2/4] block: Add errp to b{lk, drv}_truncate()

For one thing, this allows us to drop the error message generation from qemu-img.c and blockdev.c and instead have it unified in bdrv_truncate(). Signed-off-by: Max Reitz --- include/block/block.h | 2 +- include/sysemu/block-backend.h | 2 +- block.c

[Qemu-block] [PATCH v2 for-2.10 4/4] block: Add some bdrv_truncate() error messages

Add missing error messages for the drivers I am comfortable to do this in. Since one of these changes touches a mis-indented block in block/file-posix.c, this patch fixes that coding style issue along the way. Signed-off-by: Max Reitz --- block/file-posix.c | 17

[Qemu-block] [PATCH v2 for-2.10 3/4] block: Add errp to BD.bdrv_truncate()

Add an Error parameter to the block drivers' bdrv_truncate() interface. If a block driver does not set this in case of an error, the generic bdrv_truncate() implementation will do so. Where it is obvious, this patch also makes some block drivers set this value. Signed-off-by: Max Reitz

[Qemu-block] [PATCH v2 for-2.10 1/4] block/vhdx: Make vhdx_create() always set errp

This patch makes vhdx_create() always set errp in case of an error. It also adds errp parameters to vhdx_create_bat() and vhdx_create_new_region_table() so we can pass on the error object generated by blk_truncate() as of a future commit. Signed-off-by: Max Reitz ---

[Qemu-block] [PATCH v2 for-2.10 0/4] block: Add errp to b{lk, drv}_truncate()

Having an Error parameter for these functions makes sense because we sometimes want a bit more information than just "Something failed". Some drivers already use error_report() and the like to emit this additional information, so it's rather obvious that we do want a real error object here. v2:

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.9] block/archipelago: Make it compile

Am 08.03.2017 um 19:32 hat Max Reitz geschrieben: > On 08.03.2017 19:28, Eric Blake wrote: > > On 03/08/2017 12:25 PM, Eric Blake wrote: > >> On 03/08/2017 12:18 PM, Max Reitz wrote: > >>> In order to use error_setg() and similar functions, we need to include > >>> qapi/error.h. > >>> > >>>

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.9] block/archipelago: Make it compile

On 03/08/2017 03:25 PM, Eric Blake wrote: On 03/08/2017 12:18 PM, Max Reitz wrote: In order to use error_setg() and similar functions, we need to include qapi/error.h. Signed-off-by: Max Reitz --- block/archipelago.c | 1 + 1 file changed, 1 insertion(+) Reviewed-by:

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.9] block/archipelago: Make it compile

On 08.03.2017 19:28, Eric Blake wrote: > On 03/08/2017 12:25 PM, Eric Blake wrote: >> On 03/08/2017 12:18 PM, Max Reitz wrote: >>> In order to use error_setg() and similar functions, we need to include >>> qapi/error.h. >>> >>> Signed-off-by: Max Reitz >>> --- >>>

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.9] block/archipelago: Make it compile

On 03/08/2017 12:25 PM, Eric Blake wrote: > On 03/08/2017 12:18 PM, Max Reitz wrote: >> In order to use error_setg() and similar functions, we need to include >> qapi/error.h. >> >> Signed-off-by: Max Reitz >> --- >> block/archipelago.c | 1 + >> 1 file changed, 1 insertion(+)

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.9] block/archipelago: Make it compile

On 08.03.2017 19:25, Eric Blake wrote: > On 03/08/2017 12:18 PM, Max Reitz wrote: >> In order to use error_setg() and similar functions, we need to include >> qapi/error.h. >> >> Signed-off-by: Max Reitz >> --- >> block/archipelago.c | 1 + >> 1 file changed, 1 insertion(+) >

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.9] block/archipelago: Make it compile

On 03/08/2017 12:18 PM, Max Reitz wrote: > In order to use error_setg() and similar functions, we need to include > qapi/error.h. > > Signed-off-by: Max Reitz > --- > block/archipelago.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Eric Blake

[Qemu-block] [PATCH for-2.9] block/archipelago: Make it compile

In order to use error_setg() and similar functions, we need to include qapi/error.h. Signed-off-by: Max Reitz --- block/archipelago.c | 1 + 1 file changed, 1 insertion(+) diff --git a/block/archipelago.c b/block/archipelago.c index 2449cfc702..01c4ff2f7d 100644 ---

Re: [Qemu-block] [PATCH for-2.10 1/3] block: Add errp to b{lk, drv}_truncate()

On 07.03.2017 11:47, Kevin Wolf wrote: > Am 06.03.2017 um 20:54 hat Max Reitz geschrieben: >> For one thing, this allows us to drop the error message generation from >> qemu-img.c and blockdev.c and instead have it unified in >> bdrv_truncate(). >> >> Signed-off-by: Max Reitz >

Re: [Qemu-block] [PATCH for-2.10 1/3] block: Add errp to b{lk, drv}_truncate()

On 07.03.2017 11:47, Kevin Wolf wrote: > Am 06.03.2017 um 20:54 hat Max Reitz geschrieben: >> For one thing, this allows us to drop the error message generation from >> qemu-img.c and blockdev.c and instead have it unified in >> bdrv_truncate(). >> >> Signed-off-by: Max Reitz >

Re: [Qemu-block] [Qemu-devel] [PULL 00/27] Block layer fixes for 2.9.0-rc0

On 7 March 2017 at 16:40, Kevin Wolf wrote: > The following changes since commit ff79d5e939c38677a575e3493eb9b4d36eb21865: > > Merge remote-tracking branch 'remotes/xtensa/tags/20170306-xtensa' into > staging (2017-03-07 09:57:14 +) > > are available in the git repository

Re: [Qemu-block] [PATCH for-2.9 v3] file-posix: Consider max_segments for BlockLimits.max_transfer

Am 08.03.2017 um 13:08 hat Fam Zheng geschrieben: > BlockLimits.max_transfer can be too high without this fix, guest will > encounter I/O error or even get paused with werror=stop or rerror=stop. The > cause is explained below. > > Linux has a separate limit, /sys/block/.../queue/max_segments,

[Qemu-block] [PATCH for-2.9 v3] file-posix: Consider max_segments for BlockLimits.max_transfer

BlockLimits.max_transfer can be too high without this fix, guest will encounter I/O error or even get paused with werror=stop or rerror=stop. The cause is explained below. Linux has a separate limit, /sys/block/.../queue/max_segments, which in the worst case can be more restrictive than the

Re: [Qemu-block] [Qemu-devel] [PATCH RFC 1/1] vmstate: draft fix for failed iotests case 68 and 91

On 03/08/2017 08:05 AM, QingFeng Hao wrote: > > > 在 2017/3/7 18:19, Halil Pasic 写道: >> >> On 03/07/2017 11:05 AM, Kevin Wolf wrote: >>> Am 07.03.2017 um 10:54 hat Halil Pasic geschrieben: On 03/07/2017 10:29 AM, Kevin Wolf wrote: > Am 07.03.2017 um 03:53 hat QingFeng Hao

Re: [Qemu-block] [PATCH RFC 1/1] block: Handle NULL options correctly in raw_open

* Kevin Wolf [2017-03-08 10:13:46 +0100]: > Am 08.03.2017 um 03:15 hat Dong Jia Shi geschrieben: > > A normal call for raw_open should always pass in a non-NULL @options, > > but for some certain cases (e.g. trying to applying snapshot on a RBD > > image), they call raw_open

Re: [Qemu-block] [PATCH v4] backup: allow target without .bdrv_get_info

Am 28.02.2017 um 20:33 hat Vladimir Sementsov-Ogievskiy geschrieben: > Currently backup to nbd target is broken, as nbd doesn't have > .bdrv_get_info realization. > > Signed-off-by: Vladimir Sementsov-Ogievskiy Thanks, applied to the block branch. Kevin

Re: [Qemu-block] [PATCH RFC 1/1] block: Handle NULL options correctly in raw_open

Am 08.03.2017 um 03:15 hat Dong Jia Shi geschrieben: > A normal call for raw_open should always pass in a non-NULL @options, > but for some certain cases (e.g. trying to applying snapshot on a RBD > image), they call raw_open with a NULL @options right after the calling > for raw_close. > > Let's

Re: [Qemu-block] [PATCH v6 00/10] add blkdebug tests

Am 08.03.2017 um 03:54 hat Eric Blake geschrieben: > Available as a tag at: > git fetch git://repo.or.cz/qemu/ericb.git nbd-blkdebug-v6 > > v5 was: > https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg03042.html > > Since then: > - Rebase to master > - Pull in Dan's patch that splits test

Re: [Qemu-block] [PATCH v2] file-posix: Incoporate max_segments in block limit

On 08/03/2017 08:01, Fam Zheng wrote: > Linux exposes a separate limit, /sys/block/.../queue/max_segments, which > in the worst case can be more restrictive than BLKSECTGET (as they are > two different things). Similar to the BLKSECTGET story, guests don't see > this limit and send big requests