This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Systemtap for NFSv4


Ooops, -EMISSEDEMAIL...

On Fri, 25 Aug 2006 23:07:34 EDT, Trond Myklebust wrote:
> On Wed, 2006-08-23 at 09:41 -0700, Gerrit Huizenga wrote:
> > > Note: if we do want to replace dprintks with SystemTap, then I think
> > > that another precondition would be that we include the main systemtap
> > > debugging scripts in Linus' tree.
> > 
> > That has also been discussed - and I think that is a valid proposal.
> > Not sure what the current status is but if the SystemTap folks agree,
> > that is an easy discussion to start on LKML or with akpm.
> 
> Hmm.... I see that the netdev folks have started an alternative to
> systemtap when it comes to in-kernel debugging. I assume you have seen
> the file net/ipv4/tcp_probe.c?
> They use jprobes to just patch in a 'debugging module' that contains the
> printk()s that might be of interest. How about this as an alternative?

Uh so SystemTap basically allows you to do that sort of thing almost
everywhere.  Well, not exactly, but you can run any out of kernel
script based on any probe points.  And, the real bonus is that when
we have real customers cursing NFS we can carry or write a script
that does relatively arbitrary debugging things without being
constrained to learning jprobes, knowing what sort of debugging
module to patch in, without having to know what sort of kernel the
customer is running, etc.

SystemTap is way more versatile and a superset of the jprobes work at
some level, while also remaining much more accessible to systems
administrators, end users, *and* developers.  And, it provides a consistent
method for debug and is sufficiently powerful that things like
strace, oprofile, lockmeter, etc. can all be built on top of it, much
like Sun did with dtrace.

So, I'm not as keen on the tcp jprobe based solution because it is
expert friendly and isolated, as opposed to something that a broad
community is working on which will support the entire kernel debugging
and diagnosis problem set.

gerrit


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]