For those that are interested there is an open bug on this:
6266202: DTrace io provider doesn't work with ZFS
Jon.
> 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
>
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
