On Tue, May 21, 2013 at 06:46:39PM +0200, Paolo Bonzini wrote:
> Il 21/05/2013 18:26, Dietmar Maurer ha scritto:
> >> Hmm, right. But do we need the bitmap at all? We can just use
> >> > bdrv_is_allocated like bdrv_co_do_readv does.
> > Does that works with a nbd driver?
>
> Ah, right. That's t
Il 21/05/2013 18:26, Dietmar Maurer ha scritto:
>> Hmm, right. But do we need the bitmap at all? We can just use
>> > bdrv_is_allocated like bdrv_co_do_readv does.
> Does that works with a nbd driver?
Ah, right. That's the answer.
> Or does that add another RPC call (slow down)?
It doesn't wo
> Hmm, right. But do we need the bitmap at all? We can just use
> bdrv_is_allocated like bdrv_co_do_readv does.
Does that works with a nbd driver? Or does that add another RPC call (slow
down)?
> Copy-on-read modifies the topmost image even without changing the content,
> just like copy-before-write modifies the backup image.
Ah, got it. But this only works if you use a BS as target. This will not work
with my
old backup driver patches (I am still not convinced about using a BS as backu
Il 21/05/2013 17:54, Dietmar Maurer ha scritto:
Hmm, right. But do we need the bitmap at all? We can just use
> bdrv_is_allocated like bdrv_co_do_readv does.
>>> If a write occur, we read and backup that cluster immediately (out of
>>> order). So I am quite sure we need the bitmap.
>>
>>
> >> Hmm, right. But do we need the bitmap at all? We can just use
> >> > bdrv_is_allocated like bdrv_co_do_readv does.
> > If a write occur, we read and backup that cluster immediately (out of
> > order). So I am quite sure we need the bitmap.
>
> This is the same as how copy-on-read happens du
Il 21/05/2013 17:25, Dietmar Maurer ha scritto:
>> Hmm, right. But do we need the bitmap at all? We can just use
>> > bdrv_is_allocated like bdrv_co_do_readv does.
> If a write occur, we read and backup that cluster immediately (out of order).
> So
> I am quite sure we need the bitmap.
This is
> Hmm, right. But do we need the bitmap at all? We can just use
> bdrv_is_allocated like bdrv_co_do_readv does.
If a write occur, we read and backup that cluster immediately (out of order). So
I am quite sure we need the bitmap.
Il 21/05/2013 15:34, Stefan Hajnoczi ha scritto:
> /**
> * hbitmap_iter_init:
> [...]
> * position of the iterator is also okay. However, concurrent resetting of
> * bits can lead to unexpected behavior if the iterator has not yet reached
> * those bits.
> */
> void hbitmap_iter_init(HBitma
On Mon, May 20, 2013 at 01:30:37PM +0200, Paolo Bonzini wrote:
> Il 15/05/2013 16:34, Stefan Hajnoczi ha scritto:
> > +wait_for_overlapping_requests(job, start, end);
> > +cow_request_begin(&cow_request, job, start, end);
> > +
> > +for (; start < end; start++) {
> > +if (hbitma
Il 15/05/2013 16:34, Stefan Hajnoczi ha scritto:
> +wait_for_overlapping_requests(job, start, end);
> +cow_request_begin(&cow_request, job, start, end);
> +
> +for (; start < end; start++) {
> +if (hbitmap_get(job->bitmap, start)) {
> +DPRINTF("brdv_co_backup_cow ski
On Thu, May 16, 2013 at 11:27:38AM +0800, Wenchao Xia wrote:
> > +/* See if in-flight requests overlap and wait for them to complete */
> > +static void coroutine_fn wait_for_overlapping_requests(BackupBlockJob *job,
> > + int64_t start,
> > +
> From: Dietmar Maurer
>
> backup_start() creates a block job that copies a point-in-time snapshot
> of a block device to a target block device.
>
> We call backup_do_cow() for each write during backup. That function
> reads the original data from the block device before it gets
> overwritten.
From: Dietmar Maurer
backup_start() creates a block job that copies a point-in-time snapshot
of a block device to a target block device.
We call backup_do_cow() for each write during backup. That function
reads the original data from the block device before it gets
overwritten. The data is then
14 matches
Mail list logo
