Re: [Qemu-block] [PATCH v19 00/10] Block replication for continuous checkpoints

Ping here : ) Hi fam, do you have time to help reviewing this patchset? Consider of we are in the same time zone what will speed up code reviewing process, any feedback will be appreciated. Thanks -Xie On 05/20/2016 03:36 PM, Changlong Xie wrote: Block replication is a very

Re: [Qemu-block] [PATCH v19 09/10] tests: add unit test case for replication

On 05/20/2016 03:36 PM, Changlong Xie wrote: +static void io_write(BlockDriverState *bs, long pattern, int64_t pattern_count, + int64_t offset, int64_t count, bool expect_failed) +{ +void *pattern_buf; Should initialize as NULL to avoid below warnning:

Re: [Qemu-block] [Qemu-devel] [PATCH V2] block/io: optimize bdrv_co_pwritev for small requests

On Thu, 05/26 11:20, Paolo Bonzini wrote: > > > On 26/05/2016 10:30, Fam Zheng wrote: > >> > > >> > This doesn't look too wrong... Should the right sequence of events be > >> > head/after_head or head/after_tail? It's probably simplest to just emit > >> > all four events. > > I've no idea.

Re: [Qemu-block] [PATCH v3 5/5] qcow2: Catch more unaligned write_zero into zero cluster

On 05/26/2016 07:41 AM, Denis V. Lunev wrote: > On 05/26/2016 06:48 AM, Eric Blake wrote: >> is_zero_cluster() and is_zero_cluster_top_locked() are used only >> by qcow2_co_write_zeroes(). The former is too broad (we don't >> care if the sectors we are about to overwrite are non-zero, only >>

Re: [Qemu-block] [Qemu-devel] [PULL 00/31] Block layer patches

On 25 May 2016 at 18:39, Kevin Wolf wrote: > The following changes since commit 287db79df8af8e31f18e262feb5e05103a09e4d4: > > Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into > staging (2016-05-24 13:06:33 +0100) > > are available in the git

Re: [Qemu-block] [PATCH v3 5/5] qcow2: Catch more unaligned write_zero into zero cluster

On 05/26/2016 06:48 AM, Eric Blake wrote: is_zero_cluster() and is_zero_cluster_top_locked() are used only by qcow2_co_write_zeroes(). The former is too broad (we don't care if the sectors we are about to overwrite are non-zero, only that all other sectors in the cluster are zero), so it needs

[Qemu-block] [PATCH 0/2] block/mirror: Fix target backing BDS

bdrv_replace_in_backing_chain() sometimes does what is advertised (if the new node does not have a backing file yet and if it hasn't been in the same backing chain already), but this is not what the mirror block job (the sole user of that function) actually needs. In fact, it only needs this

[Qemu-block] [PATCH 1/2] block/mirror: Fix target backing BDS

Currently, we are trying to move the backing BDS from the source to the target in bdrv_replace_in_backing_chain(). However, the conditions used to decide when to move the backing BDS from source to target are not really correct. Basically, we do not have to set the target's backing BDS when doing

[Qemu-block] [PATCH 2/2] iotests: Add test for post-mirror backing chains

Signed-off-by: Max Reitz --- tests/qemu-iotests/155 | 218 + tests/qemu-iotests/155.out | 5 ++ tests/qemu-iotests/group | 1 + 3 files changed, 224 insertions(+) create mode 100755 tests/qemu-iotests/155 create mode

Re: [Qemu-block] [Qemu-devel] [PATCH V2] block/io: optimize bdrv_co_pwritev for small requests

On 26/05/2016 10:30, Fam Zheng wrote: >> > >> > This doesn't look too wrong... Should the right sequence of events be >> > head/after_head or head/after_tail? It's probably simplest to just emit >> > all four events. > I've no idea. (That's why I leaned towards fixing the test case). Well,

Re: [Qemu-block] [PATCH v3 1/5] block: split write_zeroes always

On Wed, 05/25 21:48, Eric Blake wrote: > From: "Denis V. Lunev" > > We should split requests even if they are less than write_zeroes_alignment. > For example we can have the following request: > offset 62k > size 4k > write_zeroes_alignment 64k > The original code sent 1

Re: [Qemu-block] [Qemu-devel] [PATCH V2] block/io: optimize bdrv_co_pwritev for small requests

On Thu, 05/26 09:55, Paolo Bonzini wrote: > > > On 26/05/2016 09:10, Fam Zheng wrote: > > > > diff --git a/block/io.c b/block/io.c > > index d480097..a6523cf 100644 > > --- a/block/io.c > > +++ b/block/io.c > > @@ -1435,8 +1435,10 @@ int coroutine_fn bdrv_co_pwritev(BlockDriverState > > *bs, >

Re: [Qemu-block] [PATCH 2/2] scsi-generic: Merge block max xfer len in INQUIRY response

On 26/05/2016 08:15, Fam Zheng wrote: > The rationale is similar to the above mode sense response interception: > this is practically the only channel to communicate restraints from > elsewhere such as host and block driver. > > The scsi bus we attach onto can have a larger max xfer len than

Re: [Qemu-block] [Qemu-devel] [PATCH V2] block/io: optimize bdrv_co_pwritev for small requests

On 26/05/2016 09:10, Fam Zheng wrote: > > diff --git a/block/io.c b/block/io.c > index d480097..a6523cf 100644 > --- a/block/io.c > +++ b/block/io.c > @@ -1435,8 +1435,10 @@ int coroutine_fn bdrv_co_pwritev(BlockDriverState *bs, > * than one aligned block. > */ > if

Re: [Qemu-block] [Qemu-devel] [PATCH V2] block/io: optimize bdrv_co_pwritev for small requests

On Thu, 05/26 14:50, Fam Zheng wrote: > On Tue, 05/24 16:30, Peter Lieven wrote: > > in a read-modify-write cycle a small request might cause > > head and tail to fall into the same aligned block. Currently > > QEMU reads the same block twice in this case which is > > not necessary. > > > >

Re: [Qemu-block] [PATCH V2] block/io: optimize bdrv_co_pwritev for small requests

On Tue, 05/24 16:30, Peter Lieven wrote: > in a read-modify-write cycle a small request might cause > head and tail to fall into the same aligned block. Currently > QEMU reads the same block twice in this case which is > not necessary. > > Signed-off-by: Peter Lieven Thanks,

[Qemu-block] [PATCH 0/2] block: Expose host block dev I/O size limit in scsi-block/scsi-generic

Host devices passed through as scsi-block or scsi-generic may have a compound maximum I/O limit (out of physical hardware limit, driver quirks and file system configuration, etc) that is presented in the sysfs entry. SG_IOs we issue should respect this. However the value is currently not

[Qemu-block] [PATCH 1/2] raw-posix: Fetch max sectors for host block device from sysfs

This is sometimes a useful value we should count in. Signed-off-by: Fam Zheng --- block/raw-posix.c | 47 +++ 1 file changed, 47 insertions(+) diff --git a/block/raw-posix.c b/block/raw-posix.c index a4f5a1b..d3796ad 100644 ---

[Qemu-block] [PATCH 2/2] scsi-generic: Merge block max xfer len in INQUIRY response

The rationale is similar to the above mode sense response interception: this is practically the only channel to communicate restraints from elsewhere such as host and block driver. The scsi bus we attach onto can have a larger max xfer len than what is accepted by the host file system (guarding