Date: Tue, 6 Sep 2005 12:59:03 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Nikhil Dharashivkar <nikhildharashivkar@gmail.com> Cc: Peter Jeremy <PeterJeremy@optushome.com.au>, freebsd-hackers@freebsd.org Subject: Re: Adding new option to ktrace Message-ID: <20050906125754.Y51625@fledge.watson.org> In-Reply-To: <17db6d3a050906014048e2045b@mail.gmail.com> References: <17db6d3a0509051000622868bc@mail.gmail.com> <431C8D5B.7080309@samsco.org> <431C92F2.9090104@persistent.co.in> <431C93DD.20402@samsco.org> <17db6d3a0509052203b1da14a@mail.gmail.com> <20050906081855.GA26550@cirb503493.alcatel.com.au> <17db6d3a050906014048e2045b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050906125754.Y51625>