Nikhil Dharashivkar wrote:
Yes, what rajesh saying is right , i want to print IO Bytes.
You want to capture writes coming from userland, or you want to
capture all low-level disk writes? Are you trying to correlate
these writes with a particular user process? Consider an mmaped
file. A userland program will modify the memory fronting the file,
at at some point the pagedaemon kthread will come in and flush those
dirty pages, independent of the user process. Also, like I said,
device strategy routines are decoupled from the syscall callers by
the g_down kthread. Trying to figure out the userland thread from
dastrategy that is responsible for the I/O is going to be tricky,
if even possible at all.
Scott
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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
