On Wed, Apr 24, 2013 at 12:15 PM, Paolo Bonzini <pbonz...@redhat.com> 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
