Date: Tue, 6 Sep 2005 18:18:55 +1000 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Nikhil Dharashivkar <nikhildharashivkar@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Adding new option to ktrace Message-ID: <20050906081855.GA26550@cirb503493.alcatel.com.au> In-Reply-To: <17db6d3a0509052203b1da14a@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050906081855.GA26550>