Re: [Qemu-devel] Adding Disk-Level Introspection to QEMU

[Wolfgang Richter]

On Wed, Apr 24, 2013 at 12:15 PM, Paolo Bonzini <address@hidden> wrote:

Il 24/04/2013 18:12, Wolfgang Richter ha scritto:

> In the purest form, not to miss "updates" I'm not OK with it.  But, I think
> that introspection can still _mostly_ work given these relaxed constraints.
>
> Reordered writes can be difficult to stomach though: imagine that a file inode
> update goes through before its data writes.  Imagine that the inode update
> simply extends the file size, with the last data block write coming soon
> after.
> We might incorrectly report bytes (and their contents) as belonging to this
> file before we see the final data block write if the data block is currently
> cached.

Yes, it's difficult.

In case it helps, sync points are marked by a flush command in the NBD
protocol.  At this point, the disk image is guaranteed to match the source.

You can make the SLICE_TIME shorter in block/mirror.c to ensure that
writes are more promptly replicated to the destination, but in general
it is not a problem.  QEMU can sync 10 times a second or more (with a
worst-case of 1-1.5 seconds) during a kernel compile (don't remember the
details, but something like make -j8).

Yes, I was thinking as a stop-gap solution of just using this short term until

something with stronger guarantees could be put in place. 

I think it's coming down to deciding between:

(1) New device like 'blkverify' that doesn't actual verify, but just clone

    operations

(2) Creating an active version of drive-mirror with the stronger guarantees

     (presumably turned on with an option).

--
Wolf