Re: Adding new option to ktrace

From: Nikhil Dharashivkar (nikhildharashivkar_at_gmail.com)
Date: 09/06/05

  • Next message: Nikhil Dharashivkar: "Re: Adding new option to ktrace" 
    Date: Tue, 6 Sep 2005 14:10:02 +0530
To: Peter Jeremy <PeterJeremy@optushome.com.au>

    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.
    >
    > 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"
  • Next message: Nikhil Dharashivkar: "Re: Adding new option to ktrace"

    Relevant Pages

    • Re: Adding new option to ktrace
      ... I want to give an Disk IO trace support to ktrace on FreeBSD. ... >> dumps the queue entries into a file via the normal buffer cache. ...
      (freebsd-hackers)
    • Re: Problems since 5.3-RELEASE-p15
      ... if you run ktrace on a simple program like ls: ... One final thought is that it could be the disk. ... The classic bad memory symptoms are periodic reboots, ... segmentation faults. ...
      (freebsd-questions)
    • Re: Adding new option to ktrace
      ... >> scsi driver on freebsd, ... > It's not clear how ktrace is going to help here. ... > dumps the queue entries into a file via the normal buffer cache. ... firmly believed to be a SCSI layer problem, since process level I/O events ...
      (freebsd-hackers)