Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Wed, 2009-01-21 at 20:47 -0200, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 22, 2009 at 09:36:53AM +1100, Greg Banks escreveu:
> > Chuck Lever wrote:
> > >
> > >
> > > I think we need to visit this issue on a case-by-case basis.   
> > > Sometimes dprintk is appropriate.  Sometimes printk(KERN_ERR).   
> > > Sometimes a performance metric.
> > Well said.
> > 
> > > Trond has always maintained that dprintk() is best for developers, but  
> > > probably inappropriate for field debugging,
> > It's not a perfect tool but it beats nothing at all.
> > >  and I think that may also  
> > > apply to trace points.  
> > It depends on whether distros can be convinced to enable it by default,
> > and install by default any necessary userspace infrastructure.   The
> > most important thing for field debugging is Just Knowing that you have
> > all the bits necessary to perform useful debugging without having to
> > find some RPM that matches the kernel that the machine is actually
> > running now, and not the one that was present when the machine was
> > installed.
> 
> Exactly, that is why an ftrace plugin, that only when selected using
> echo "nfs" > /debug/tracing/current_tracer will activate the tracepoints
> and provide output via /debug/tracing/trace or /deb/tracing/trace_pipe,
> possibly combined with other ftrace plugins such as the stacktrace,
> blktrace, etc.
> 
> I.e. no need at all for any matching userspace tool, near zero impact
> when not activated, useful, if done right, for both developers and for
> admins.
> 
> Again, an example can be found in the blktrace ftrace plugin[1], that
> instead of adding a requirement will eventually drop an existing, well
> established one (blktrace(8)).

I must be missing something. Exactly what functionality does this then
give us that we don't have already with the existing RPC/NFS dprintk()
scheme?

Trond