Adding new option to ktrace
rwatson at FreeBSD.org
Tue Sep 6 04:57:44 PDT 2005
On Tue, 6 Sep 2005, Peter Jeremy wrote:
> On Tue, 2005-Sep-06 10:33:53 +0530, Nikhil Dharashivkar wrote:
>> Thanks for replying me. Basically what happend, while testing
>> scsi driver on freebsd, at some point it crashes. So, there is no way
>> to know how much IO is performed. To know the IO state just before the
>> driver fails, i selected ktrace to print IO information whatever i ll
>> get from dastrategy routine.
> It's not clear how ktrace is going to help here. The ktrXXX(9)
> functions place ktr_request events in a queue. A kernel thread then
> dumps the queue entries into a file via the normal buffer cache. The
> data on disk is typically about 30 seconds behind real time. If the
> system crashes, you will lose any events that are still in the buffer
> cache or ktr_todo queue.
> Another problem is that since ktrace generates disk I/O, it is likely to
> disturb your testing.
> A better approach would seem to be to build a circular buffer and store
> the I/O requests in the buffer. When the system crashes, you can look
> at the last entries in the buffer.
ktrace is indeed probably the wrong layer to do this analysis, if it is
firmly believed to be a SCSI layer problem, since process level I/O events
often map weakly to device level I/O events -- i.e., directory operations
are substantially divorced from the block operations that implement them
due to soft updates, write buffering, write combining, etc.
KTR(9) supports tracing of GEOM-layer I/O events to an in-memory buffer
which can be retrieved from a coredump using ktrdump. Adding additional
instrumentation, say in CAM or a device driver, is pretty straight forward
and probably a useful way to approach this problem.
Robert N M Watson
More information about the freebsd-hackers