From: Erik Walthinsen <omega@pdxcolo.net>
To: nfs@lists.sourceforge.net
Subject: Converting open filehandles to pathnames
Date: Sat, 08 May 2004 16:33:28 -0700 [thread overview]
Message-ID: <1084059203.714.13.camel@omikron> (raw)
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
next reply other threads:[~2004-05-09 6:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-08 23:33 Erik Walthinsen [this message]
2004-05-09 7:24 ` Converting open filehandles to pathnames Greg Banks
2004-05-09 0:43 ` Erik Walthinsen
2004-05-10 0:26 ` seth vidal
2004-05-10 3:00 ` Garrick Staples
2004-05-09 21:11 ` Erik Walthinsen
2004-05-10 8:02 ` Bogdan Costescu
2004-05-10 14:20 ` Erik Walthinsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1084059203.714.13.camel@omikron \
--to=omega@pdxcolo.net \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.