Re: [Qemu-block] [PATCH v3 05/10] block: add transactional callbacks feature

2015-04-23 Thread Max Reitz
On 23.04.2015 02:04, John Snow wrote: The goal here is to add a new method to transactions that allows developers to specify a callback that will get invoked only once all jobs spawned by a transaction are completed, allowing developers the chance to perform actions conditionally pending

Re: [Qemu-block] [PATCH v3 08/10] qmp: Add an implementation wrapper for qmp_drive_backup

2015-04-23 Thread Max Reitz
On 23.04.2015 02:04, John Snow wrote: We'd like to be able to specify the callback given to backup_start manually in the case of transactions, so split apart qmp_drive_backup into an implementation and a wrapper. Switch drive_backup_prepare to use the new wrapper, but don't overload the

Re: [Qemu-block] [PATCH v3 10/10] iotests: 124 - transactional failure test

2015-04-23 Thread Max Reitz
On 23.04.2015 02:04, John Snow wrote: Use a transaction to request an incremental backup across two drives. Coerce one of the jobs to fail, and then re-run the transaction. Verify that no bitmap data was lost due to the partial transaction failure. Signed-off-by: John Snow js...@redhat.com ---

Re: [Qemu-block] [PATCH v3 09/10] block: drive_backup transaction callback support

2015-04-23 Thread Max Reitz
On 23.04.2015 02:04, John Snow wrote: This patch actually implements the transactional callback system for the drive_backup action. (1) We manually pick up a reference to the bitmap if present to allow its cleanup to be delayed until after all drive_backup jobs launched by the

Re: [Qemu-block] [PATCH v3 02/10] iotests: add transactional incremental backup test

2015-04-23 Thread Max Reitz
On 23.04.2015 02:04, John Snow wrote: Test simple usage cases for using transactions to create and synchronize incremental backups. Signed-off-by: John Snow js...@redhat.com --- tests/qemu-iotests/124 | 54 ++ tests/qemu-iotests/124.out | 4

Re: [Qemu-block] [PATCH v6 00/21] block: transactionless incremental backup series

2015-04-23 Thread John Snow
On 04/23/2015 09:19 AM, Stefan Hajnoczi wrote: On Fri, Apr 17, 2015 at 07:49:48PM -0400, John Snow wrote: === v6: === 01: s/underlaying/underlying/ Removed a reference to 'disabled' bitmaps. Touching up inconsistent list indentation. Added FreeBSD Documentation License,

Re: [Qemu-block] [PATCH v6 20/21] iotests: add incremental backup failure recovery test

2015-04-23 Thread Stefan Hajnoczi
On Fri, Apr 17, 2015 at 07:50:08PM -0400, John Snow wrote: Test the failure case for incremental backups. Signed-off-by: John Snow js...@redhat.com Reviewed-by: Max Reitz mre...@redhat.com --- tests/qemu-iotests/124 | 57 ++

Re: [Qemu-block] [PATCH v6 21/21] iotests: add incremental backup granularity tests

2015-04-23 Thread Stefan Hajnoczi
On Fri, Apr 17, 2015 at 07:50:09PM -0400, John Snow wrote: Test what happens if you fiddle with the granularity. Reviewed-by: Max Reitz mre...@redhat.com Signed-off-by: John Snow js...@redhat.com --- tests/qemu-iotests/124 | 58 +-

[Qemu-block] [Question] the problem about driver-mirror

2015-04-23 Thread 张敏
I test the function of driver-mirror when run io stress test in vm. The fio's model is 128 iodepth, 4K block-size, 100% write, 100% randon. This is a continuous test, and then I start drive-mirror to copy data to other image file. I find this job can't finish. I analysis the problem and find the

Re: [Qemu-block] [Qemu-devel] [PATCH v6 00/21] block: transactionless incremental backup series

2015-04-23 Thread John Snow
On 04/23/2015 03:18 PM, Eric Blake wrote: On 04/23/2015 08:41 AM, John Snow wrote: I know I said primarily to be difficult but I was just being facetious. I didn't find the GPL2+ to be suitable for documentation, strictly, so I went to read up on the documentation licenses that the fsf

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Wen Congyang
On 04/23/2015 05:26 PM, Paolo Bonzini wrote: On 23/04/2015 11:00, Kevin Wolf wrote: Because it may be the right design. If you're really worried about the test matrix, put a check in the filter block driver that its bs-file is qcow2. Of course, such an artificial restriction looks a bit

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Paolo Bonzini
On 23/04/2015 11:00, Kevin Wolf wrote: Because it may be the right design. If you're really worried about the test matrix, put a check in the filter block driver that its bs-file is qcow2. Of course, such an artificial restriction looks a bit ugly, but using a bad design just in order to

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Stefan Hajnoczi
On Wed, Apr 22, 2015 at 05:28:01PM +0800, Wen Congyang wrote: On 04/22/2015 05:18 PM, Stefan Hajnoczi wrote: On Tue, Apr 21, 2015 at 05:28:01PM +0200, Paolo Bonzini wrote: On 21/04/2015 03:25, Wen Congyang wrote: Please do not introduce name+colo block drivers. This approach is invasive

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Paolo Bonzini
On 23/04/2015 12:17, Kevin Wolf wrote: Perhaps quorum is not a great match after all, and it's better to add a new colo driver similar to quorum but simpler and only using the read policy that you need for colo. The new driver would also know how to use BDRV_O_NO_CONNECT. In any case

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Paolo Bonzini
On 23/04/2015 12:40, Kevin Wolf wrote: The question that is still open for me is whether it would be a colo.c or an active-mirror.c, i.e. if this would be tied specifically to COLO or if it could be kept generic enough that it could be used for other use cases as well. Understood (now).

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Wen Congyang
On 04/23/2015 05:55 PM, Stefan Hajnoczi wrote: On Wed, Apr 22, 2015 at 05:28:01PM +0800, Wen Congyang wrote: On 04/22/2015 05:18 PM, Stefan Hajnoczi wrote: On Tue, Apr 21, 2015 at 05:28:01PM +0200, Paolo Bonzini wrote: On 21/04/2015 03:25, Wen Congyang wrote: Please do not introduce name+colo

Re: [Qemu-block] [PATCH] qcow2: do lazy allocation of the L2 cache

2015-04-23 Thread Stefan Hajnoczi
On Wed, Apr 22, 2015 at 04:37:15PM +0200, Alberto Garcia wrote: On Wed 22 Apr 2015 12:26:02 PM CEST, Stefan Hajnoczi wrote: Large disk images need large L2 caches in order to maximize their I/O performance. However setting a correct size for the cache is not necessarily easy since apart

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Wen Congyang
On 04/23/2015 05:00 PM, Kevin Wolf wrote: Am 22.04.2015 um 12:12 hat Paolo Bonzini geschrieben: On 22/04/2015 11:31, Kevin Wolf wrote: Actually I liked the foo+colo names. These are just internal details of the implementations and the primary/secondary disks actually can be any format.

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Paolo Bonzini
On 23/04/2015 11:14, Wen Congyang wrote: The bs-file-driver should support backing file, and use backing reference already. What about the primary side? We should control when to connect to NBD server, not in nbd_open(). My naive suggestion could be to add a BDRV_O_NO_CONNECT option to

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Dr. David Alan Gilbert
* Paolo Bonzini (pbonz...@redhat.com) wrote: On 23/04/2015 14:05, Dr. David Alan Gilbert wrote: As presented at the moment, I don't see there's any dynamic reconfiguration on the primary side at the moment So that means the bdrv_start_replication and bdrv_stop_replication callbacks

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Paolo Bonzini
On 23/04/2015 14:19, Dr. David Alan Gilbert wrote: So that means the bdrv_start_replication and bdrv_stop_replication callbacks are more or less redundant, at least on the primary? In fact, who calls them? Certainly nothing in this patch set... :) In the main colo set (I'm looking

Re: [Qemu-block] [PATCH v6 00/21] block: transactionless incremental backup series

2015-04-23 Thread Stefan Hajnoczi
On Fri, Apr 17, 2015 at 07:49:48PM -0400, John Snow wrote: === v6: === 01: s/underlaying/underlying/ Removed a reference to 'disabled' bitmaps. Touching up inconsistent list indentation. Added FreeBSD Documentation License, primarily to be difficult Please stick to the

Re: [Qemu-block] [PATCH v6 06/21] hbitmap: cache array lengths

2015-04-23 Thread Stefan Hajnoczi
On Fri, Apr 17, 2015 at 07:49:54PM -0400, John Snow wrote: As a convenience: between incremental backups, bitmap migrations and bitmap persistence we seem to need to recalculate these a lot. Because the lengths are a little bit-twiddly, let's just solidly cache them and be done with it.

Re: [Qemu-block] [PATCH v6 15/21] block: Resize bitmaps on bdrv_truncate

2015-04-23 Thread Stefan Hajnoczi
On Fri, Apr 17, 2015 at 07:50:03PM -0400, John Snow wrote: Signed-off-by: John Snow js...@redhat.com --- block.c| 18 ++ include/qemu/hbitmap.h | 10 ++ util/hbitmap.c | 48 3 files changed, 76

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Paolo Bonzini
On 23/04/2015 13:36, Kevin Wolf wrote: Crap. Then we need to figure out dynamic reconfiguration for filters (CCed Markus and Jeff). And this is really part of the fundamental operation mode and not just a way to give users a way to change their mind at runtime? Because if it were, we

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Dr. David Alan Gilbert
* Paolo Bonzini (pbonz...@redhat.com) wrote: On 23/04/2015 13:36, Kevin Wolf wrote: Crap. Then we need to figure out dynamic reconfiguration for filters (CCed Markus and Jeff). And this is really part of the fundamental operation mode and not just a way to give users a way to

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Wen Congyang
On 04/23/2015 06:44 PM, Paolo Bonzini wrote: On 23/04/2015 12:40, Kevin Wolf wrote: The question that is still open for me is whether it would be a colo.c or an active-mirror.c, i.e. if this would be tied specifically to COLO or if it could be kept generic enough that it could be used for

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Kevin Wolf
Am 23.04.2015 um 12:44 hat Paolo Bonzini geschrieben: On 23/04/2015 12:40, Kevin Wolf wrote: The question that is still open for me is whether it would be a colo.c or an active-mirror.c, i.e. if this would be tied specifically to COLO or if it could be kept generic enough that it could be

Re: [Qemu-block] [PATCH for-2.4 V2 0/9] various improvements for the iSCSI driver

2015-04-23 Thread Stefan Hajnoczi
On Thu, Apr 16, 2015 at 04:08:24PM +0200, Peter Lieven wrote: v1-v2: - removed the requirement for libiscsi 1.10.0 [Paolo] - reworked to force_next_flush logic [Paolo] Peter Lieven (9): block/iscsi: do not forget to logout from target block/iscsi: change all iscsilun properties

Re: [Qemu-block] [PATCH COLO v3 01/14] docs: block replication's description

2015-04-23 Thread Wen Congyang
On 04/24/2015 10:01 AM, Fam Zheng wrote: On Thu, 04/23 14:23, Paolo Bonzini wrote: On 23/04/2015 14:19, Dr. David Alan Gilbert wrote: So that means the bdrv_start_replication and bdrv_stop_replication callbacks are more or less redundant, at least on the primary? In fact, who calls them?