Yes, what rajesh saying is right , i want to print IO Bytes.
On 9/6/05, Scott Long <[EMAIL PROTECTED]> 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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
