Hi,
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. None of the unknown
filenames are created and/or deleted during the dtrace. They are all
VM images, which only get modified. zpool scrub doesn''t show any
errors.
Looking in the code I think that zfs_vget in zfs_vfsops.c gets called
for filename resolution. But I can''t figure out why this fails for
certain files. Allways the same files get resolved.
Thank for looking into this.
Frederik
David Pacheco
2011-Jul-20 16:20 UTC
[zfs-discuss] [dtrace-discuss] dtrace nfs requests on a zfs filesystem
On Wed, Jul 20, 2011 at 7:10 AM, wessels <wessels147 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110720/a30d4ed4/attachment.html>
Kyle Hailey
2011-Jul-20 16:40 UTC
[zfs-discuss] [dtrace-discuss] dtrace nfs requests on a zfs filesystem
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 <dap at joyent.com> wrote:> On Wed, Jul 20, 2011 at 7:10 AM, wessels <wessels147 at 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-discuss at opensolaris.org >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110720/f6a02b95/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 821 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110720/f6a02b95/attachment.png>
wessels
2011-Jul-20 19:53 UTC
[zfs-discuss] [dtrace-discuss] dtrace nfs requests on a zfs filesystem
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.hailey at 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 <dap at joyent.com> wrote: > >> On Wed, Jul 20, 2011 at 7:10 AM, wessels <wessels147 at 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-discuss at opensolaris.org >> > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110720/861f2dc8/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 821 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110720/861f2dc8/attachment-0001.png>
Casper.Dik at oracle.com
2011-Jul-21 07:09 UTC
[zfs-discuss] [dtrace-discuss] dtrace nfs requests on a zfs filesystem
>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.The pathnames are cached with the vnode but they are only created when the filename is looked up (open, stat, etc). Find will look up all the files; but without that, it won''t know the name. NFSv3 is stateless and the look up could have been done a long time ago (the server might be rebooted). Casper