On Aug 22, 2008, at 7:31 AM, Ben Rockwood wrote:
> 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. ;)
yep - you won't see filenames from iosnoop on zfs since it doesn't
call bdev_strategy() directly which is what io:::start works with ..
this came up last year with Mauro on the zfs-discuss alias .. if
you're looking for file pathnames take a look at the following example
I whipped up after that discussion for use on a project to track
timings to zfs based files (which can be particularly enlightening.)
#!/usr/sbin/dtrace -s
# pragma D option quiet
zfs_write:entry,
zfs_read:entry,
zfs_putpage:entry,
zfs_getpage:entry
{
self->ts = timestamp;
self->filepath = args[0]->v_path;
}
zfs_write:return,
zfs_read:return,
zfs_putpage:return,
zfs_getpage:return
/self->ts && self->filepath/
{
printf("%s on %s took %d nsecs\n", probefunc,
stringof(self->filepath), timestamp - self->ts);
self->ts = 0;
self->filepath = 0;
}
---
for IO sizes and counts though .. take a look at the calls to extract
the right arguments you might be looking for
---
.je
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
