On Thu, Oct 21, 2010 at 6:20 AM, Christoph Hellwig <[email protected]> wrote: > On Tue, Oct 19, 2010 at 03:29:51PM +0100, Richard W.M. Jones wrote: >> On Tue, Oct 19, 2010 at 03:59:36PM +0200, Jan Kiszka wrote: >> > Once we have "-trace events=...", defining the list of active >> > tracepoints before starting qemu will be trivial (e.g. via a config >> > file). Of course, this requires that all tracepoints are built-in... >> >> Sorry that I've not been following this very closely, but does this >> sort of thing allow tracing reads and writes to block devices? Am I >> right in thinking that if a tracepoint existed in the right place, one >> could get a log file from that which could be post-processed in >> another tool? > > I don't think it does. But I have a patch that I need to update which > outputs traces in the form of the Linux blktrace block I/O tracing tool, > which does exactly what you need (and more). You can simply use > all the blktrace-enabled tools, including seekwatcher on it.
There are trace events in qemu.git today that let you trace block read/write operations (device, sector, length, r/w information is there). Look at bdrv_aio_readv and bdrv_aio_writev in the trace-events file. I can see the value of using existing tools to parse blktrace data. On the other hand blktrace is taylored to Linux's block layer and QEMU can only map to a subset of it. I'm interested in your patch too, is it a new block protocol or does it hook directly into block.c? Stefan
