John Dzilvelis wrote:
> Hello, 
> I have recently started using iosnoop from the dtrace toolkit to monitor file 
> level io. It works great (!) on ufs file systems, but I am unable to see any 
> file names when monitoring processes running on a zfs file system. As is 
> documented, "<none>" is displayed for the file name when it can not be 
> determined from the file system.  
> Ideally I would like to gather file level ( named) IO Read/Write Bytes as 
> well as IO Read/Write Counts, like the output of iosnoop.  
> During my search of the list archives it appears that this issue came up in 
> March 2008. But I haven't been able to determine if there was a resolution. 
> If there has not been a solution to this, then it would be great if someone 
> could point me in the right direction so that I can experiment with some 
> other probes. I've noticed that the fbt provider has many zfs related probes, 
> but I am unable to find the docs that describe them individually in detail. 

Tracing IO through ZFS is very complex because of the various layers
through which IO passes.  If you want to watch arbitrary file io
requests you'll want to stick with syscall probes and the like.
DTracing IO at a high level is easy, same at a low level, its the in
between with ZFS thats tough.

The FBT provider exposes every functions entry and return, so for a
given fbt:zfs:whatever probe just look for that function in the ZFS code
(cvs.opensolaris.org).

How you trace will depend on what you want to know, but I find that a
good starting point is to aggregate callstacks from low level zio
functions, thus allowing me to see how we got there; ie: dtrace
'fbt:zfs:zio_read:entry{ @[stack(20)] = count(); }'.  Based on the call
stack I can use other FBT probes to explore.  When all else fails I have
gone so far as to trace every function in the kernel (this works for
about 1-2 seconds and produces an output file around 500M on my personal
workstation at home)... not something I'd do in production but an
amazing learning experience. ;)

benr.
_______________________________________________
dtrace-discuss mailing list
[email protected]

Reply via email to