io:::start probe does not seem to get zfs filenames in args[2]->fi_pathname. Any ideas how to get this info? -neel
Hi Neel - Thanks for pushing this out. I''ve been tripping over this for
a while.
You can instrument zfs_read() and zfs_write() to reliably track filenames:
#!/usr/sbin/dtrace -s
#pragma D option quiet
zfs_read:entry,
zfs_write:entry
{
printf("%s of %s\n",probefunc, stringof(args[0]->v_path));
}
I''m not sure why the io:::start does not work for ZFS. I
didn''t spend
any real time on this,
but it appears none of the ZFS code calls bdev_strategy() directly, and
instrumenting bdev_strategy:enter (which is where io:::start lives) to track
filenames via stringof(args[0]->b_vp->v_path) does not work either.
Use the zfs r/w function entry points for now.
What sayeth the ZFS team regarding the use of a stable DTrace provider
with their file system?
Thanks,
/jim
Neelakanth Nadgir wrote:> io:::start probe does not seem to get zfs filenames in
> args[2]->fi_pathname. Any ideas how to get this info?
> -neel
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
Jim I can''t use zfs_read/write as the file is mmap()''d so no read/write! -neel On Sep 26, 2007, at 5:07 AM, Jim Mauro <James.Mauro at Sun.COM> wrote:> > Hi Neel - Thanks for pushing this out. I''ve been tripping over this > for a while. > > You can instrument zfs_read() and zfs_write() to reliably track > filenames: > > #!/usr/sbin/dtrace -s > > #pragma D option quiet > > zfs_read:entry, > zfs_write:entry > { > printf("%s of %s\n",probefunc, stringof(args[0]->v_path)); > } > > > > I''m not sure why the io:::start does not work for ZFS. I didn''t > spend any real time on this, > but it appears none of the ZFS code calls bdev_strategy() directly, > and > instrumenting bdev_strategy:enter (which is where io:::start lives) > to track > filenames via stringof(args[0]->b_vp->v_path) does not work either. > > Use the zfs r/w function entry points for now. > > What sayeth the ZFS team regarding the use of a stable DTrace > provider with their file system? > > Thanks, > /jim > > > Neelakanth Nadgir wrote: >> io:::start probe does not seem to get zfs filenames in >> args[2]->fi_pathname. Any ideas how to get this info? >> -neel >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss at opensolaris.org >> http://mail.opensolar
> What sayeth the ZFS team regarding the use of a stable DTrace provider > with their file system? >For the record, the above has a tone to it that I really did not intend (antagonistic?), so.... I had a good chat with Roch about this. The file pathname is derived via a translator from the vnode v_path structure member, and thus requires an instantiated vnode when the probe fires - this is why instrumenting bdev_strategy:entry and tracing args[0]->b_vp->v_path has the same problem; no vnode. An alternative approach to tracking filenames with IOs is using the fsinfo provider (Solaris 10 Update 2) . This is a handy place to start: #!/usr/sbin/dtrace -s #pragma D option quiet fsinfo::: / execname != "dtrace" / { @[execname, args[0]->fi_pathname, args[0]->fi_fs, probename] = count(); } END { printf("%-16s %-24s %-8s %-16s %-8s\n","EXEC","PATH","FS","NAME","COUNT"); printa("%-16s %-24s %-8s %-16s %- at 8d\n",@); } Which yields... EXEC PATH FS NAME COUNT gnome-panel /zp ufs lookup 1 gnome-panel /zp/home zfs lookup 1 gnome-panel /zp/home/mauroj zfs lookup 1 gnome-panel /zp/home/mauroj/.recently-used.xbel.HKF3YT zfs getattr 1 gnome-panel /zp/home/mauroj/.recently-used.xbel.HKF3YT zfs lookup 1 <snip> metacity <unknown> sockfs poll 1031 vmware-user <unknown> sockfs poll 1212 Xorg <unknown> sockfs rwlock 1573 Xorg <unknown> sockfs rwunlock 1573 gnome-terminal <unknown> sockfs poll 2084 dbwriter /zp/space zfs realvp 4254 dbwriter /zp/space zfs remove 4254 dbwriter /zp/space/f33 zfs close 4254 dbwriter /zp/space/f33 zfs lookup 4254 dbwriter /zp/space/f33 zfs read 4254 dbwriter /zp/space/f33 zfs realvp 4254 dbwriter /zp/space/f33 zfs seek 4254 dbwriter /zp/space/f33 zfs write 4254 dbwriter /zp/space zfs getsecattr 4255 dbwriter /zp/space/f33 zfs ioctl 4255 dbwriter /zp/space/f33 zfs open 4255 dbwriter <unknown> zfs create 4255 dbwriter /zp/space/f33 zfs rwunlock 8508 dbwriter /zp/space zfs lookup 8509 dbwriter /zp/space/f33 zfs rwlock 8509 dbwriter /zp ufs lookup 8515 Thanks, /jim
Neelakanth Nadgir writes:
> io:::start probe does not seem to get zfs filenames in
> args[2]->fi_pathname. Any ideas how to get this info?
> -neel
>
Who says an I/O is doing work for a single pathname/vnode
or for a single process. There is not that one to one
correspondance anymore. Not in the ZIL and not in the
transaction groups due to I/O aggregations.
As for mmaped I/O, follow Jim''s advice, I guess fsflush will
be issueing some putpage :
fsinfo genunix fop_putpage putpage
-r
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Hey Neel - Try this:
nv70b> cat zfs_page.d
#!/usr/sbin/dtrace -s
#pragma D option quiet
zfs_putpage:entry
{
printf("zfs write to %s\n",stringof(args[0]->v_path));
}
zfs_getpage:entry
{
printf("zfs read from %s\n",stringof(args[0]->v_path));
}
I did some quick tests with mmap''d ZFS files, and it seems to work....
/jim
Neelakanth Nadgir wrote:> Jim I can''t use zfs_read/write as the file is mmap()''d so
no read/write!
>
> -neel
>
> On Sep 26, 2007, at 5:07 AM, Jim Mauro <James.Mauro at Sun.COM>
wrote:
>
>
>> Hi Neel - Thanks for pushing this out. I''ve been tripping over
this
>> for a while.
>>
>> You can instrument zfs_read() and zfs_write() to reliably track
>> filenames:
>>
>> #!/usr/sbin/dtrace -s
>>
>> #pragma D option quiet
>>
>> zfs_read:entry,
>> zfs_write:entry
>> {
>> printf("%s of %s\n",probefunc,
stringof(args[0]->v_path));
>> }
>>
>>
>>
>> I''m not sure why the io:::start does not work for ZFS. I
didn''t
>> spend any real time on this,
>> but it appears none of the ZFS code calls bdev_strategy() directly,
>> and
>> instrumenting bdev_strategy:enter (which is where io:::start lives)
>> to track
>> filenames via stringof(args[0]->b_vp->v_path) does not work
either.
>>
>> Use the zfs r/w function entry points for now.
>>
>> What sayeth the ZFS team regarding the use of a stable DTrace
>> provider with their file system?
>>
>> Thanks,
>> /jim
>>
>>
>> Neelakanth Nadgir wrote:
>>
>>> io:::start probe does not seem to get zfs filenames in
>>> args[2]->fi_pathname. Any ideas how to get this info?
>>> -neel
>>>
>>> _______________________________________________
>>> zfs-discuss mailing list
>>> zfs-discuss at opensolaris.org
>>> http://mail.opensolar
>>>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
Jim Mauro wrote:> Hi Neel - Thanks for pushing this out. I''ve been tripping over this for > a while. > > You can instrument zfs_read() and zfs_write() to reliably track filenames: > > #!/usr/sbin/dtrace -s > > #pragma D option quiet > > zfs_read:entry, > zfs_write:entry > { > printf("%s of %s\n",probefunc, stringof(args[0]->v_path)); > }FYI, this tracks the system calls made (which may hit in the cache), whereas io:::start tracks i/o sent down to the disk driver.> What sayeth the ZFS team regarding the use of a stable DTrace provider > with their file system?Sounds like a good idea. However, as others discussed, the data needed to do that is not immediately available. --matt