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

[Wolfgang Richter]

On Tue, May 14, 2013 at 4:50 AM, Kevin Wolf <address@hidden> wrote:

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.

Yes! Active mirroring is precisely what is needed to implement block-level

introspection.

 

You're leaving out the most interesting section: How should block-trace
be implemented?

Noted, although maybe folding it into 'drive-mirror' as an 'active' option

might be best, now that Paolo has spoken up.

 

The other question is how to implement it internally. I don't think
adding specific code for each new block job into bdrv_co_do_writev() is
acceptable. We really need a generic way to intercept I/O operations.
The keyword from earlier discussions is "block filters". Essentially the
idea is that the block job temporarily adds a BlockDriverState on top of
the format driver and becomes able to implement all callbacks it likes
to intercept. The bad news is that the infrastructure isn't there yet
to actually make this happen in a sane way.

Yeah, I'd also really love block filters and probably would have

originally used them instead of the tracing subsystem originally if they

existed.  It would make implementing all kinds of 'block-level' features

much, much easier. 

--
Wolf