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] |
On 7/27/06, Li Guanglei <guanglei@cn.ibm.com> wrote:When we started working on NFS trace hooks, we realized it is not an easy task. Although we use NFS in daily work but we don't have much knowledge about the NFS protocol details and its implementation inside the Kernel. So I divided the work into two steps. At the first step I need get a list of trace points. And at the second step I need to make sure what trace data is available for each trace hook. In a short, the trace data available for each hook will be derived from the arguments of the kernel functions being probed.
We read through the Kernel source code and chose some functions to be instrumented. We will trace the entry of these functions and if necessary, the return of them will also be traced. The following is the list of these functions, please take a review:
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?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |