qemu-devel
[Top][All Lists]
Advanced

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

Re: Tracing block devices (was: Re: [Qemu-devel] Static tracepoint contr


From: Stefan Hajnoczi
Subject: Re: Tracing block devices (was: Re: [Qemu-devel] Static tracepoint control via trace-event)
Date: Thu, 21 Oct 2010 10:04:07 +0100

On Thu, Oct 21, 2010 at 6:20 AM, Christoph Hellwig <address@hidden> 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



reply via email to

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