I was aware of that suggestion but found it so ugly that I never tried it. I ditched pride and embraced pragmatism. And yes running find did resolve all names. Could you be so kind and trouble the gentleman down the hall and ask them what's happening and why? Perhaps something can be done about it in code. With some pointers I might look into it.
Thanks again. On Wed, Jul 20, 2011 at 6:40 PM, Kyle Hailey <kyle.hai...@delphix.com>wrote: > > I've had issues like this as well. Fortunately Eric Schrock and Adam > Leventhal work down the all from me and I ran this past them. Eric had the > suggestion to simply do a "find" from the directory that I'm interested in > getting file names for and that did the trick. For example all of my tracing > is on > > /domain0 > > so I simply do > > $ cd /domain0 > $ find . > /dev/null > > and then do my tracing. Since adding this trick, I haven't had problems > with "unknown" > > - Kyle Hailey > > O: +1.415.341.3430 > F: +1.650.494.1676 > 275 Middlefield Road, Suite 50 > Menlo Park, CA 94025 > http://www.delphix.com > > On Wed, Jul 20, 2011 at 9:20 AM, David Pacheco <d...@joyent.com> wrote: > >> On Wed, Jul 20, 2011 at 7:10 AM, wessels <wessels...@gmail.com> wrote: >> >>> I'm issuing the following statement on a ONNV_104 (I know a bit old >>> but very stable) NFS server: >>> # dtrace -n 'nfsv3:::op-read-start,nfsv3:::op-write-start >>> {@[probefunc,args[1]->noi_curpath]=count(); }' >>> >>> which works fine...most of the time but not always. >>> Usually it resolve's the filenames on which the I/O are done but not >>> always. It displays <unknown> as filename. >> >> >> >> There's this: >> >> >> http://mail.opensolaris.org/pipermail/dtrace-discuss/2010-February/008527.html >> >> -- Dave >> >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-disc...@opensolaris.org >> > > > >
<<image.png>>
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
