[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Wolfgang Richter
Subject: Re: [Qemu-devel] [RFC] block-trace Low Level Command Supporting Disk Introspection
Date: Tue, 14 May 2013 11:45:19 -0400

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

Yes! Active mirroring is precisely what is needed to implement block-level
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. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]