Read through the kvm thread (I'm not on that mailing just just for reference; thanks for the CC). I saw you're hooking a different function than me (not sure it matters). I hook bdrv_co_writev and I operate on the passed in iovector datastructure there writing out its contents and a short header to stderr where my introspection tools interpret it. I don't maintain a full shadow copy of the disk, but it conceptually shouldn't matter. Are you working on the iovec data structure as well? Also, is your disk format raw? I don't think it should matter, but I was just wondering. -- Wolf On Wed, Aug 14, 2013 at 11:02 AM, Wolfgang Richter <wolf@xxxxxxxxxx> wrote: > On Wed, Aug 14, 2013 at 10:43 AM, Spensky, Chad - 0559 - MITLL > <chad.spensky@xxxxxxxxxx> wrote: >> Wolf, >> >> We're able to get all of the meta data just fine. > > I assume by meta-data you mean (essentially) "function" call > parameters within QEMU as to the (1) location of the write on disk, > and (2) the amount of data being written out (in bytes). > >> However it seems that >> the actual content of the read/write seems to be wrong some of the time. > > That's very odd, I'm pretty sure I never had that bug (although I > might silently have it!). > > I did occasionally observe a kernel accidentally writing out kernel > buffers that hadn't been cleared to disk (guest kernel) :-) > >> The first 2 sectors seem to always be correct, however on some writes, the >> data that we traced does not match up with the data we are actually seeing >> in the .img file for the guest on disk. > > Are you certain you're getting every write? Sometimes things might be > written to rapidly in succession? > > How are you obtaining the shadow copy of the write stream (maybe there > was earlier stuff in this thread I should read up on)? > > -- > Wolf -- Wolf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
