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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
