On Tue, May 14, 2013 at 4:50 AM, Kevin Wolf <kw...@redhat.com> 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
