Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Sep 2005 14:10:02 +0530
From:      Nikhil Dharashivkar <nikhildharashivkar@gmail.com>
To:        Peter Jeremy <PeterJeremy@optushome.com.au>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Adding new option to ktrace
Message-ID:  <17db6d3a050906014048e2045b@mail.gmail.com>
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
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 ?



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.
>=20
> 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.
>=20
> Another problem is that since ktrace generates disk I/O, it is likely
> to disturb your testing.
>=20
> 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.
>=20
> --
> Peter Jeremy
>=20


--=20
Thanks and Regards,
         Nikhil.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17db6d3a050906014048e2045b>