Adding new option to ktrace
Robert Watson
rwatson at FreeBSD.org
Tue Sep 6 04:59:05 PDT 2005
On Tue, 6 Sep 2005, Nikhil Dharashivkar wrote:
> Yes, it is ok if i loose data in ktrace queue when crash occurs.
> Basically, I want to give an Disk IO trace support to ktrace on FreeBSD.
> So, what I am thinking to use struct dio in dastrategy routine to
> trace the IO. I 'll use this struct to generate ktr_request. Throught
> ktr_writerequest it will be written in ktrace.out .
> Is it possible ?
Try taking a look at KTR(9) and ktrdump(8) for information on ktr, the
in-kernel trace facility. ktrace(1) is almost entirely about tracing
process level system call behavior, and not structured for kernel event
tracing except in that context. I think you'll find KTR(9) is much more
what you're looking for, and among other things, you can extract the
results from both live kernels and kernel crash dumps.
Robert N M Watson
>
>
>
> On 9/6/05, Peter Jeremy <PeterJeremy at optushome.com.au> 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.
>>
>> --
>> Peter Jeremy
>>
>
>
> --
> Thanks and Regards,
> Nikhil.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>
More information about the freebsd-hackers
mailing list