Re: [Qemu-block] [Qemu-devel] [PATCH v2] spec/qcow2: bitmaps: zero bitmap table offset

On 06/30/2016 07:40 PM, John Snow wrote: On 06/30/2016 05:12 AM, Denis V. Lunev wrote: On 06/30/2016 10:34 AM, Vladimir Sementsov-Ogievskiy wrote: After loading bitmap from image and setting IN_USE flag in it's header, corresponding data (bitmap table and data clusters) becomes inconsistent

Re: [Qemu-block] [Qemu-devel] [PATCH] spec/parallels: fix a mistake

On 06/30/2016 01:12 PM, Denis V. Lunev wrote: > On 06/30/2016 07:43 PM, John Snow wrote: >> >> On 06/30/2016 04:15 AM, Vladimir Sementsov-Ogievskiy wrote: >>> We have only one flag for now - Empty Image flag. >>> >>> Signed-off-by: Vladimir Sementsov-Ogievskiy >>> ---

Re: [Qemu-block] [Qemu-devel] [PATCH] spec/parallels: fix a mistake

On 06/30/2016 07:43 PM, John Snow wrote: On 06/30/2016 04:15 AM, Vladimir Sementsov-Ogievskiy wrote: We have only one flag for now - Empty Image flag. Signed-off-by: Vladimir Sementsov-Ogievskiy --- docs/specs/parallels.txt | 2 +- 1 file changed, 1 insertion(+),

Re: [Qemu-block] [Qemu-devel] [PATCH] spec/parallels: fix a mistake

On 06/30/2016 04:15 AM, Vladimir Sementsov-Ogievskiy wrote: > We have only one flag for now - Empty Image flag. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > docs/specs/parallels.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [Qemu-block] [Qemu-devel] [PATCH v2] spec/qcow2: bitmaps: zero bitmap table offset

On 06/30/2016 05:12 AM, Denis V. Lunev wrote: > On 06/30/2016 10:34 AM, Vladimir Sementsov-Ogievskiy wrote: >> After loading bitmap from image and setting IN_USE flag in it's header, >> corresponding data (bitmap table and data clusters) becomes inconsistent >> and is no longer needed. It is

Re: [Qemu-block] [PATCH 1/1] mirror: fix request throttling in drive-mirror

On Wed, Jun 22, 2016 at 03:35:27PM +0300, Denis V. Lunev wrote: > There are 2 deficiencies here: > - mirror_iteration could start several requests inside. Thus we could > simply have more in_flight requests than MAX_IN_FLIGHT. > - keeping this in mind throttling in mirror_run which is checking >

Re: [Qemu-block] [PATCH 1/1] mirror: fix request throttling in drive-mirror

On Wed, Jun 22, 2016 at 03:35:27PM +0300, Denis V. Lunev wrote: > There are 2 deficiencies here: > - mirror_iteration could start several requests inside. Thus we could > simply have more in_flight requests than MAX_IN_FLIGHT. > - keeping this in mind throttling in mirror_run which is checking >

Re: [Qemu-block] [PATCH] block/iscsi: precache the allocation status of a target

On 30/06/2016 13:08, Peter Lieven wrote: > this fills up the allocationmap at iscsi_open. This helps > to reduce the number of get_block_status requests during runtime > significantly. > > Signed-off-by: Peter Lieven > --- > block/iscsi.c | 16 > 1 file changed,

[Qemu-block] [PATCH v2 4/6] block/qdev: Allow configuring rerror/werror with qdev properties

The rerror/werror policies are implemented in the devices, so that's where they should be configured. In comparison to the old options in -drive, the qdev properties are only added to those devices that actually support them. If the option isn't given (or "auto" is specified), the setting of the

[Qemu-block] [PATCH v2 5/6] qemu-iotests: Test setting WCE with qdev

Signed-off-by: Kevin Wolf --- tests/qemu-iotests/157 | 92 ++ tests/qemu-iotests/157.out | 22 +++ tests/qemu-iotests/group | 1 + 3 files changed, 115 insertions(+) create mode 100755 tests/qemu-iotests/157 create

[Qemu-block] [PATCH v2 6/6] block: Remove BB options from blockdev-add

werror/rerror are now available as qdev options. The stats-* options are removed without an existing replacement; they should probably be configurable with a separate QMP command like I/O throttling settings. Removing id is left for another day because this involves updating qemu-iotests cases to

[Qemu-block] [PATCH v2 0/6] block: Move BB options from blockdev-add to qdev

This series adds some device level options (write-cache, werror, rerror) to qdev that used to be specified with -drive and made their way into blockdev-add. They are at the same time removed from blockdev-add, which is going to be changed in a later patch series so that it only creates block nodes

[Qemu-block] [PATCH v2 2/6] block/qdev: Allow configuring WCE with qdev properties

As cache.writeback is a BlockBackend property and as such more related to the guest device than the BlockDriverState, we already removed it from the blockdev-add interface. This patch adds the new way to set it, as a qdev property of the corresponding guest device. For example: -drive

[Qemu-block] [PATCH v2 3/6] commit: Fix use of error handling policy

Commit implemented the 'enospc' policy as 'ignore' if the error was not ENOSPC. The QAPI documentation promises that it's treated as 'stop'. Using the common block job error handling function fixes this. Signed-off-by: Kevin Wolf --- block/commit.c | 6 +++--- 1 file changed,

[Qemu-block] [PATCH v2 1/6] block/qdev: Allow node name for drive properties

If a node name instead of a BlockBackend name is specified as the driver for a guest device, an anonymous BlockBackend is created now. Signed-off-by: Kevin Wolf --- hw/core/qdev-properties-system.c | 22 +++--- 1 file changed, 19 insertions(+), 3 deletions(-)

Re: [Qemu-block] [PATCH v2 02/15] blockjob: Decouple the ID from the device name in the BlockJob struct

On Wed 29 Jun 2016 07:20:55 PM CEST, Max Reitz wrote: I thought adding a new 'ID' field was simpler. The device name is still a device name (where it makes sense). The default ID is guaranteed to be valid and guaranteed not to clash with user-defined IDs. The API is (in my

[Qemu-block] [PATCH] block/iscsi: precache the allocation status of a target

this fills up the allocationmap at iscsi_open. This helps to reduce the number of get_block_status requests during runtime significantly. Signed-off-by: Peter Lieven --- block/iscsi.c | 16 1 file changed, 16 insertions(+) diff --git a/block/iscsi.c

[Qemu-block] [PATCH V4] block/iscsi: allow caching of the allocation map

until now the allocation map was used only as a hint if a cluster is allocated or not. If a block was not allocated (or Qemu had no info about the allocation status) a get_block_status call was issued to check the allocation status and possibly avoid a subsequent read of unallocated sectors. If a

Re: [Qemu-block] [PATCH v2] spec/qcow2: bitmaps: zero bitmap table offset

On 06/30/2016 10:34 AM, Vladimir Sementsov-Ogievskiy wrote: After loading bitmap from image and setting IN_USE flag in it's header, corresponding data (bitmap table and data clusters) becomes inconsistent and is no longer needed. It is better to free bitmap table and corresponding clusters from

Re: [Qemu-block] [PATCH 1/1] spec/parallels: fix a mistake

On Thu, Jun 30, 2016 at 11:19:30AM +0300, Denis V. Lunev wrote: > From: Vladimir Sementsov-Ogievskiy > > We have only one flag for now - Empty Image flag. The patch fixes unused > bits specification and marks bit 1 as usused. > > Signed-off-by: Vladimir

[Qemu-block] [PATCH 1/1] spec/parallels: fix a mistake

From: Vladimir Sementsov-Ogievskiy We have only one flag for now - Empty Image flag. The patch fixes unused bits specification and marks bit 1 as usused. Signed-off-by: Vladimir Sementsov-Ogievskiy Signed-off-by: Denis V. Lunev

[Qemu-block] [PATCH] spec/parallels: fix a mistake

We have only one flag for now - Empty Image flag. Signed-off-by: Vladimir Sementsov-Ogievskiy --- docs/specs/parallels.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/specs/parallels.txt b/docs/specs/parallels.txt index b4fe229..e9271eb

[Qemu-block] [PATCH v2] spec/qcow2: bitmaps: zero bitmap table offset

After loading bitmap from image and setting IN_USE flag in it's header, corresponding data (bitmap table and data clusters) becomes inconsistent and is no longer needed. It is better to free bitmap table and corresponding clusters from the image immediately after loading the bitmap than free them