Date: Tue, 6 Sep 2005 12:57:42 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: freebsd-hackers@freebsd.org, Nikhil Dharashivkar <nikhildharashivkar@gmail.com> Subject: Re: Adding new option to ktrace Message-ID: <20050906125551.I51625@fledge.watson.org> In-Reply-To: <20050906081855.GA26550@cirb503493.alcatel.com.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050906125551.I51625>