Re: [Qemu-devel] [RFC] block-trace Low Level Command Supporting Disk Introspection

[Paolo Bonzini]

Il 14/05/2013 17:48, Wolfgang Richter ha scritto:
> On Tue, May 14, 2013 at 6:04 AM, Paolo Bonzini <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Il 14/05/2013 10:50, Kevin Wolf ha scritto:
>     > Or, to translate it into our existing terminology, drive-mirror
>     > implements a passive mirror, you're proposing an active one (which we
>     > do want to have).
>     >
>     > With an active mirror, we'll want to have another choice: The
>     mirror can
>     > be synchronous (guest writes only complete after the mirrored
>     write has
>     > completed) or asynchronous (completion is based only on the original
>     > image). It should be easy enough to support both once an active mirror
>     > exists.
> 
>     Right, I'm waiting for Stefan's block-backup to give me the "right"
>     hooks for the active mirror.
> 
>     The bulk phase will always be passive, but an active-asynchronous mirror
>     has some interesting properties and it makes sense to implement it.
> 
> 
> Do you mean you'd model the 'active' mode after 'block-backup,' or actually
> call functions provided by 'block-backup'?

No, I'll just reuse the same hooks within block/mirror.c (almost... it
looks like I need after_write too, not just before_write :( that's a
pity).  Basically:

1) before the write, if there is space in the job's buffers, allocate a
MirrorOp and a data buffer for the write.  Also record whether the block
was dirty before;

2) after the write, do nothing if there was no room to allocate the data
buffer.  Else clear the block from the dirty bitmap.  If the block was
dirty, read the whole cluster from the source as in passive mirroring.
If it wasn't, copy the data from guest memory to the preallocated buffer
and write it to the destination;

> If I knew more about what you
> had in mind, I wouldn't mind trying to add this 'active' mode to
> 'drive-mirror'
> and test it with my use case.  I want to avoid duplicate work, so if you
> want to implement it yourself I can defer this.

Also the other way round.  If you want to give it a shot based on the
above spec just tell me.

It should require no changes to block.c except for adding after_write.

Paolo