Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Mar 2009 22:15:48 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r190293 - in head/sys: cddl/dev/dtnfsclient modules/dtrace modules/dtrace/dtnfsclient modules/dtrace/dtraceall nfsclient sys
Message-ID:  <alpine.BSF.2.00.0903222209290.85640@fledge.watson.org>
In-Reply-To: <200903222207.n2MM7qK3085361@svn.freebsd.org>
References:  <200903222207.n2MM7qK3085361@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Mar 2009, Robert Watson wrote:

>  Add dtnfsclient, a first cut at an NFSv2/v3 client reuest DTrace
>  provider.  The NFS client exposes 'start' and 'done' probes for NFSv2
>  and NFSv3 RPCs when using the new RPC implementation, passing in the
>  vnode, mbuf chain, credential, and NFSv2 or NFSv3 procedure number.
>  For 'done' probes, the error number is also available.
>
>  Probes are named in the following way:
>
>    ...
>    nfsclient:nfs2:write:start
>    nfsclient:nfs2:write:done
>    ...
>    nfsclient:nfs3:access:start
>    nfsclient:nfs3:access:done
>    ...
>

An example script to profile time spent waiting on NFS RPCs in NFSv3 by system 
call:

   syscall:::entry
   {

           self->count = 0;
   }

   nfsclient:nfs3::start
   {

           self->timestamp = timestamp;
   }

   nfsclient:nfs3::done
   {

           self->count += (timestamp - self->timestamp);
   }

   syscall:::return
   /self->count != 0/
   {

           @syscalls[probefunc] = quantize(self->count);
   }

The script could easily be expanded to look at RPC delays associated with page 
faults, etc.

Something Solaris does in their prototype DTrace server probes is summarize 
network information for the remote host (local + remote address) and provide a 
pathname for the vnode being accessed (if available).  It would be easy to do 
something along those lines here, although when I glanced at a recent 
opensolaris tree it looked like their server probes hadn't made it back into 
hg yet.  However, it would be easy to imagine one or both of these behaviors 
here being very useful (summarize I/O by pathname, latency by server, etc), 
which would currently require DTrace scripts to grub around a lot.

Robert N M Watson
Computer Laboratory
University of Cambridge



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0903222209290.85640>