Date: Tue, 6 Sep 2005 10:19:21 +0530 From: Nikhil Dharashivkar <nikhildharashivkar@gmail.com> To: Scott Long <scottl@samsco.org> Cc: freebsd-hackers@freebsd.org, "Rajesh S. Ghanekar" <rajesh_ghanekar@persistent.co.in>, freebsd-scsi@freebsd.org Subject: Re: Adding new option to ktrace Message-ID: <17db6d3a05090521494a284c01@mail.gmail.com> In-Reply-To: <431C93DD.20402@samsco.org> References: <17db6d3a0509051000622868bc@mail.gmail.com> <431C8D5B.7080309@samsco.org> <431C92F2.9090104@persistent.co.in> <431C93DD.20402@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Yes, what rajesh saying is right , i want to print IO Bytes.
On 9/6/05, Scott Long <scottl@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 monito=
r
> >>> 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
> >
>=20
> 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.
>=20
> Scott
>=20
--=20
Thanks and Regards,
Nikhil.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17db6d3a05090521494a284c01>