On Tue, Apr 23, 2013 at 01:40:19PM -0400, Wolfgang Richter wrote: > > -- > Wolf > > On Apr 23, 2013, at 1:22 PM, Eric Blake <ebl...@redhat.com> wrote: > > > On 04/23/2013 11:12 AM, Wolfgang Richter wrote: > >> I'm interested in adding introspection of disk writes to QEMU for various > >> applications and research potential. > >> > >> What I mean by introspection of disk writes is that, when enabled, each > >> write > >> passing through QEMU to backing storage would also be copied to an > >> introspection channel for further analysis. > > > > Sounds like you would be benefited by the block-backup series, with an > > NBD server as the point where you inject your introspection. > > > > https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg04629.html > > > > The existing drive-mirror command can also target an NBD destination, > > with similar effects. > > Yes, OK as a new member to the list I saw the block-backup series and was > starting to have similar thoughts. I'll port my code (analysis side) to work > with it (or drive-mirror). > > Has there been any performance analysis of drive-mirror (impact on executing > guest)?
It slows down guest I/O for a couple of reasons: 1. Writes now require a read from the original device followed by a write to the target device. Only after this completes is the write allowed to proceed. 2. Overlapping read/write requests are serialized to maintain consistency between the guests I/Os and the block-backup I/Os. But on second thought, I don't think block-backup fits the bill. You don't care about the original data, you care about what new data the guest is writing. I think what you really want is a "tap" block driver which mirrors writes to a target device (typically a NBD volume). You can model this on blkverify or check out Benoit Canet's quorum patches. Stefan
