On 04/22/2015 06:04 PM, John Snow wrote:
> This adds two qmp commands to transactions.
>
> block-dirty-bitmap-add allows you to create a bitmap simultaneously
> alongside a new full backup to accomplish a clean synchronization
> point.
>
> block-dirty-bitmap-clear allows you to reset a bitmap bac
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
---
tests/qemu-iotests/124 | 120 ++
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 callback and closure yet.
Signed-off-by: John S
Allow bitmap successors to carry reference counts.
We can in a later patch use this ability to clean up the dirty bitmap
according to both the individual job's success and the success of all
jobs in the transaction group.
The code for cleaning up a bitmap is also moved from backup_run to
backup_c
Now that the structure formerly known as BlkTransactionState has been
renamed to something sensible (BlkActionState), re-introduce an actual
BlkTransactionState that actually manages state for the entire Transaction.
In the process, convert the old QSIMPLEQ list of actions into a QTAILQ,
to let us
This adds two qmp commands to transactions.
block-dirty-bitmap-add allows you to create a bitmap simultaneously
alongside a new full backup to accomplish a clean synchronization
point.
block-dirty-bitmap-clear allows you to reset a bitmap back to as-if
it were new, which can also be used alongsid
Test simple usage cases for using transactions to create
and synchronize incremental backups.
Signed-off-by: John Snow
---
tests/qemu-iotests/124 | 54 ++
tests/qemu-iotests/124.out | 4 ++--
2 files changed, 56 insertions(+), 2 deletions(-)
diff
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 transaction have fully completed.
(2) We create a
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 complete success,
partial failure, or complete f
requires: 1429314609-29776-1-git-send-email-js...@redhat.com
"[PATCH v6 00/21] block: transactionless incremental backup series"
This series adds support for incremental backup primitives in QMP
transactions. It requires my transactionless incremental backup series,
currently at v6.
Pat
If we want to get at the job after the life of the job,
we'll need a refcount for this object.
This may occur for example if we wish to inspect the actions
taken by a particular job after a transactional group of jobs
runs, and further actions are required.
Signed-off-by: John Snow
Reviewed-by:
These structures are misnomers, somewhat.
(1) BlockTransactionState is not state for a transaction,
but is rather state for a single transaction action.
Rename it "BlkActionState" to be more accurate.
(2) The BdrvActionOps describes operations for the BlkActionState,
above. This name
On 04/22/2015 06:18 PM, Eric Blake wrote:
On 04/17/2015 05:50 PM, John Snow wrote:
Add the "frozen" status booleans, to inform clients
when a bitmap is occupied doing a task.
Signed-off-by: Fam Zheng
Signed-off-by: John Snow
Reviewed-by: Max Reitz
Reviewed-by: Stefan Hajnoczi
Reviewed-by:
On 04/17/2015 05:50 PM, John Snow wrote:
> Add the "frozen" status booleans, to inform clients
> when a bitmap is occupied doing a task.
>
> Signed-off-by: Fam Zheng
> Signed-off-by: John Snow
> Reviewed-by: Max Reitz
> Reviewed-by: Stefan Hajnoczi
> Reviewed-by: Eric Blake
> ---
> block.c
On 04/17/2015 05:49 PM, John Snow wrote:
> For "dirty-bitmap" sync mode, the block job will iterate through the
> given dirty bitmap to decide if a sector needs backup (backup all the
> dirty clusters and skip clean ones), just as allocation conditions of
> "top" sync mode.
>
> Signed-off-by: Fam
On 04/17/2015 05:49 PM, John Snow wrote:
> We add a bitmap merge operation to assist in error cases
> where we wish to combine two bitmaps together.
>
> This is algorithmically O(bits) provided HBITMAP_LEVELS remains
> constant. For a full bitmap on a 64bit machine:
> sum(bits/64^k, k, 0, HBITMAP_
On 04/16/2015 09:12 AM, Alberto Garcia wrote:
> This patch makes the 'device' paramater of the 'block-stream' command
s/paramater/parameter/
> accept a node name as well as a device name.
>
> In addition to that, operation blockers will be checked in all
> intermediate nodes between the top and
On 04/16/2015 09:12 AM, Alberto Garcia wrote:
> Currently, block jobs can only be owned by root nodes. This patch
> allows block jobs to be in any arbitrary node, by making the following
> changes:
>
> - Block jobs can now be identified by the node name of their
> BlockDriverState in addition to
On 04/16/2015 09:12 AM, Alberto Garcia wrote:
> The current way to obtain the list of existing block jobs is to
> iterate over all root nodes and check which ones own a job.
>
> Since we want to be able to support block jobs in other nodes as well,
> this patch keeps a list of jobs that is updated
On 04/16/2015 09:12 AM, Alberto Garcia wrote:
> This adds test_stream_intermediate(), similar to test_stream() but
> streams to the intermediate image instead.
>
> Signed-off-by: Alberto Garcia
> ---
> tests/qemu-iotests/030 | 18 +-
> tests/qemu-iotests/030.out | 4 ++--
>
On Wed 22 Apr 2015 09:38:40 PM CEST, Eric Blake wrote:
> You know, we should _also_ test a no-op stream, to prove that we
> handle it correctly (we've had bugs in the past where 0-length active
> commit behaved differently in the events it generated than non-zero
> length), and your change is drop
On 04/16/2015 09:12 AM, Alberto Garcia wrote:
> This test is streaming to the top layer using the intermediate image
> as the base. This is a mistake since block-stream never copies data
> from the base image and its backing chain, so this is effectively a
> no-op.
>
> In addition to fixing the ba
On 04/16/2015 09:12 AM, Alberto Garcia wrote:
> Signed-off-by: Alberto Garcia
> ---
> docs/live-block-ops.txt | 30 +++---
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/docs/live-block-ops.txt b/docs/live-block-ops.txt
> index a257087..3bf86be 10064
On 04/17/2015 05:49 PM, John Snow wrote:
> Signed-off-by: John Snow
> ---
> docs/bitmaps.md | 352
>
> 1 file changed, 352 insertions(+)
> create mode 100644 docs/bitmaps.md
>
Reviewed-by: Eric Blake
--
Eric Blake eblake redhat com
On 16.04.2015 17:12, Alberto Garcia wrote:
This adds test_stream_intermediate(), similar to test_stream() but
streams to the intermediate image instead.
Signed-off-by: Alberto Garcia
---
tests/qemu-iotests/030 | 18 +-
tests/qemu-iotests/030.out | 4 ++--
2 files change
On 16.04.2015 17:12, Alberto Garcia wrote:
This test is streaming to the top layer using the intermediate image
as the base. This is a mistake since block-stream never copies data
from the base image and its backing chain, so this is effectively a
no-op.
In addition to fixing the base parameter,
On 16.04.2015 17:12, Alberto Garcia wrote:
Signed-off-by: Alberto Garcia
---
docs/live-block-ops.txt | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
Reviewed-by: Max Reitz
On 18.04.2015 01:50, John Snow wrote:
Signed-off-by: John Snow
---
block.c| 18 ++
include/qemu/hbitmap.h | 10 ++
util/hbitmap.c | 48
3 files changed, 76 insertions(+)
Reviewed-by: Max Reitz
On 16.04.2015 17:12, Alberto Garcia wrote:
This patch makes the 'device' paramater of the 'block-stream' command
accept a node name as well as a device name.
In addition to that, operation blockers will be checked in all
intermediate nodes between the top and the base node.
Since qmp_block_stre
On 16.04.2015 17:12, Alberto Garcia wrote:
This makes sure that the image we are steaming into is open in
read-write mode during the operation.
Operation blockers are also set in all intermediate nodes, since they
will be removed from the chain afterwards.
Finally, this also unblocks the stream
On 16.04.2015 17:12, Alberto Garcia wrote:
Currently, block jobs can only be owned by root nodes. This patch
allows block jobs to be in any arbitrary node, by making the following
changes:
- Block jobs can now be identified by the node name of their
BlockDriverState in addition to the device
On 18.04.2015 01:50, John Snow wrote:
A filter is added to allow callers to request very specific
events to be pulled from the event queue, while leaving undesired
events still in the stream.
This allows us to poll for completion data for multiple asynchronous
events in any arbitrary order.
A n
On 18.04.2015 01:49, John Snow wrote:
For "dirty-bitmap" sync mode, the block job will iterate through the
given dirty bitmap to decide if a sector needs backup (backup all the
dirty clusters and skip clean ones), just as allocation conditions of
"top" sync mode.
Signed-off-by: Fam Zheng
Signed
On 18.04.2015 01:49, John Snow wrote:
We add a bitmap merge operation to assist in error cases
where we wish to combine two bitmaps together.
This is algorithmically O(bits) provided HBITMAP_LEVELS remains
constant. For a full bitmap on a 64bit machine:
sum(bits/64^k, k, 0, HBITMAP_LEVELS) ~= 1.
On 18.04.2015 01:49, John Snow wrote:
Signed-off-by: John Snow
---
docs/bitmaps.md | 352
1 file changed, 352 insertions(+)
create mode 100644 docs/bitmaps.md
Reviewed-by: Max Reitz
On 17.04.2015 20:23, John Snow wrote:
On 04/17/2015 09:33 AM, Max Reitz wrote:
On 09.04.2015 00:20, John Snow wrote:
A filter is added to allow callers to request very specific
events to be pulled from the event queue, while leaving undesired
events still in the stream.
This allows to poll f
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 from the image size, it also depends on
>> other factors like its
On 04/03/2015 04:01 AM, Wen Congyang wrote:
> Signed-off-by: Wen Congyang
> Signed-off-by: zhanghailiang
> Signed-off-by: Gonglei
> Cc: Luiz Capitulino
> Cc: Michael Roth
> Reviewed-by: Paolo Bonzini
> ---
> block.c | 40
> include/b
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> Signed-off-by: Wen Congyang
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Yang Hongyang
> Signed-off-by: zhanghailiang
> Signed-off-by: Gonglei
> ---
> docs/block-replication.txt | 153
> +
> 1 file
On Tue, Apr 21, 2015 at 06:20:39PM +0300, Alberto Garcia 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 from the image size, it also depends
> on other factors like its
On Fri, Apr 17, 2015 at 02:52:43PM +0300, Alberto Garcia wrote:
> The image field in BlockDeviceInfo is supposed to contain an ImageInfo
> object. However that is being filled in by bdrv_query_info(), not by
> bdrv_block_device_info(), which is where BlockDeviceInfo is actually
> created.
>
> Anyo
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.
>>
>> Stefan, what was your worry with the +colo block drivers?
>
> I haven't read the patc
On 04/22/2015 05:29 PM, Stefan Hajnoczi wrote:
> On Tue, Apr 21, 2015 at 09:25:59AM +0800, Wen Congyang wrote:
>> On 04/20/2015 11:30 PM, Stefan Hajnoczi wrote:
>>> On Fri, Apr 03, 2015 at 06:01:07PM +0800, Wen Congyang wrote:
>>> One general question about the design: the Secondary host needs 3x
>
Am 21.04.2015 um 17:28 hat Paolo Bonzini geschrieben:
>
>
> On 21/04/2015 03:25, Wen Congyang wrote:
> >> > Please do not introduce "+colo" block drivers. This approach is
> >> > invasive and makes block replication specific to only a few block
> >> > drivers, e.g. NBD or qcow2.
> > NBD is used
On Tue, Apr 21, 2015 at 09:25:59AM +0800, Wen Congyang wrote:
> On 04/20/2015 11:30 PM, Stefan Hajnoczi wrote:
> > On Fri, Apr 03, 2015 at 06:01:07PM +0800, Wen Congyang wrote:
> > One general question about the design: the Secondary host needs 3x
> > storage space since it has the Secondary Disk,
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 "+colo" block drivers. This approach is
> invasive and makes block replication specific to only a few block
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 "+colo" block drivers. This approach is
> >> > invasive and makes block replication specific to only a few block
> >> > drivers, e.g. NBD or qcow2.
> > NBD is us
47 matches
Mail list logo
