Adding new option to ktrace

Nikhil Dharashivkar nikhildharashivkar at gmail.com
Mon Sep 5 21:49:23 PDT 2005


Yes, what rajesh saying is right , i want to print IO Bytes.

On 9/6/05, Scott Long <scottl at samsco.org> wrote:
> Rajesh S. Ghanekar wrote:
> > Scott Long wrote:
> >
> >> Nikhil Dharashivkar wrote:
> >>
> >>> Hi,
> >>>    i want to hack the ktrace system call. Basically, I want to monitor
> >>> scsi disk IO through dastrategy() routine.
> >>>     It seems that kern_ktrace.c implements different functions for
> >>> ktrace options like -tc / -ti ... etc (see man page). So, is it
> >>> possible to add new option for disk IO with new structure object
> >>> containing disk io information which will be pass to
> >>> ktr_submittrequest thr' ktr_request structure.
> >>>          Will data will be written correctly in ktrace.out and will
> >>> kdump analyze that ?
> >>>
> >>>
> >>>
> >>
> >> What are you trying to monitor?  Would the existing devstat interface
> >> work?
> >
> >
> > May be he requires how many bytes transferred (read/write) while a
> > process is executing.
> > I guess devstat doesn't do it from process context, it gives total IO
> > read/writes from a device,
> > if registred via devstat. Please correct me if I am wrong.
> >
> >
> > - Rajesh
> >
> 
> There isn't a 1:1 correlation between the bytes that the userland
> program writes, and the bytes that actually get written to disk.
> Filesystem metadata writes will happen if the file needs to be
> extended, not to mention the access time being updated.  Some writes
> won't even originate from a userland program, like swap writes.
> GEOM also decouples the I/O path, so it's not the user process that
> will actually do the write, it's the g_down kthread.  I would think
> that this would make tracking I/O via ktrace very hard.
> 
> Scott
> 


-- 
Thanks and Regards,
         Nikhil.


More information about the freebsd-hackers mailing list