This is the mail archive of the
mailing list for the systemtap project.
Re: [NFS] [ltc-perf] draft of nfs event hook
- From: Li Guanglei <guanglei at cn dot ibm dot com>
- To: Chuck Lever <chucklever at gmail dot com>
- Cc: "systemtap at sourceware dot org" <systemtap at sourceware dot org>, nfs at lists dot sourceforge dot net
- Date: Fri, 28 Jul 2006 06:47:02 +0800
- Subject: Re: [NFS] [ltc-perf] draft of nfs event hook
- Organization: IBM CSTL
- References: <OF053E04B8.D96A9ADC-ON482571B7.0031B2AD-482571B7.00323E27@cn.ibm.com> <44C8C631.email@example.com> <firstname.lastname@example.org>
Have you done this with a local file system? I assume yes, and that
you just described the general approach you have taken with other file
systems. I think getting the same kind of data and trace points from
the NFS client as you added to local file systems would be good.
Capturing VFS and address space entry points is definitely useful and
is similar to local file systems. At the bottom of the NFS client is
the RPC client, and it acts just like the block I/O layer does for
local file systems. Would you consider adding trace points in the
LKET for the RPC client and server?
What I didn't list about NFS operations includes authentication,
NFSv4 callback and RPC(I prefer to use a separate set of trace hooks
for RPC). I am not sure if these operations are also required to be
traced. If I missed some important functions or I listed some
redundant functions, please feel free to let me know. Any comments
will be highly appreciated.
I didn't list RPC here because I think RPC is not only used by NFS and
I need another set of RPC trace hooks to address the RPC server and
client side operations. That will be my plan of the next set of trace