This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Systemtap for NFSv4
- From: Gerrit Huizenga <gh at us dot ibm dot com>
- To: Trond Myklebust <trond dot myklebust at fys dot uio dot no>
- Cc: Tony Reix <tony dot reix at bull dot net>, Li Guanglei <guanglei at cn dot ibm dot com>, Vara Prasad <varap at us dot ibm dot com>, Jose Santos <jrs at us dot ibm dot com>, "systemtap at sourceware dot org" <systemtap at sourceware dot org>, xuepengl at cn dot ibm dot com
- Date: Wed, 30 Aug 2006 14:59:20 -0700
- Subject: Re: Systemtap for NFSv4
- Reply-to: Gerrit Huizenga <gh at us dot ibm dot com>
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