From: Erik Walthinsen <omega@pdxcolo.net>
Subject: Converting open filehandles to pathnames
Date: Sat, 08 May 2004 16:33:28 -0700
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <1084059203.714.13.camel@omikron>
Mime-Version: 1.0
Content-Type: text/plain
To: nfs@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

I've got an NFS server with client machines running User-mode Linux. 
These UML instances open several large files on the NFS server at boot
time (root, /home, etc), and perform varying amounts of IO over the next
several months, or however long the UML instances are running.

The problem is, I really have no concrete way of determining IO load on
these files.  Nothing distinguishes the packets for one file from
packets for another file coming from the same physical host machine. 
Except the filehandle that is.

A while ago I wrote a script that caught every NFS packet and used
periodic getattr RPC calls to complete a mapping between the filehandles
and inodes (and thus pathnames), and it mostly worked.  However,
something has changed and these getattr calls have ceased.  Thus, the
script happily gathers read and write calls but has no means of
translating them.

My question: is there some means of divining the device/inode of a
filehandle?  I looked around the NFS and VFS code and found nothing that
looked promising, but I don't really understand the VFS subsystem.

(aside: some net sources indicate that Solaris has a /var/nfs/fhtable
that it keeps up to date, but that's related to nfslogd and various
other Sun-isms)

Would it be possible to write a program to walk through kmem from some
known global kernel symbol to find the relevant structures necessary to
perform this translation?  (Ideally, on an existing production system,
passively)  If so, what symbol would be the base of such a trip?  If
someone can explain roughly what the relevant structure tree looks like,
I can figure out how to write the necessary code, but until I have a
clue about the relevant VFS/NFS code, I'm lost.

TIA,
   Omega
   aka Erik Walthinsen
   omega@pdxcolo.net


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs