hi,all
recently, I want to get some information (like file access patten)
from a trace of NFS client. The simplest way may be parse the file
handle to get the file ino and directory ino, but I don't know how to
get them from the 64 of 16 hexadecimal. Can you tell me how to parse
file handle to get useful information, thanks very much.
best regards=A3=A1
Jing
PS, there is some file handles from the trace
bcdaa400ce7a23012000000000a4dabcce7a230164860000a0cf90002e303000
b7905500246c6a1220000000000cec5413b72e3264860000a0cf90002e303000
bcdaa400ce7a23012000000000a4dabcce7a230164860000a0cf90002e303000
bcdaa400ce7a230120000000004ad8e8f8b2230164860000a0cf90002e303000
bcdaa400ce7a230120000000004ad8e8f8b2230164860000a0cf90002e303000
bcdaa400ce7a230120000000001074cd975e480564860000a0cf90002e303000
On May. 19, 2008, 11:14 +0300, xing jing <[email protected]> wrote:
> hi,all
> recently, I want to get some information (like file access patten)
> from a trace of NFS client. The simplest way may be parse the file
> handle to get the file ino and directory ino, but I don't know how to
> get them from the 64 of 16 hexadecimal. Can you tell me how to parse
> file handle to get useful information, thanks very much.
>=20
> best regards=A3=A1
>=20
> Jing
>=20
>=20
> PS, there is some file handles from the trace
>=20
> bcdaa400ce7a23012000000000a4dabcce7a230164860000a0cf90002e303000
> b7905500246c6a1220000000000cec5413b72e3264860000a0cf90002e303000
> bcdaa400ce7a23012000000000a4dabcce7a230164860000a0cf90002e303000
> bcdaa400ce7a230120000000004ad8e8f8b2230164860000a0cf90002e303000
> bcdaa400ce7a230120000000004ad8e8f8b2230164860000a0cf90002e303000
> bcdaa400ce7a230120000000001074cd975e480564860000a0cf90002e303000
What server generated them?
This doesn't look like the linux nfsd format (as defined in
include/linux/nfsd/nfsfh.h)
That file handle contents are opaque to the client so you'd
need to have the server's code or reverse engineer its
structure.
Try running ls -li on a file and parent directory and see if
you can identify the respective inode numbers in the filehandle.
(likely to be coded in big-endian)
Benny
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
At 04:56 AM 5/19/2008, Benny Halevy wrote:
>On May. 19, 2008, 11:14 +0300, xing jing <[email protected]> wrote:
>> recently, I want to get some information (like file access patten)
>> from a trace of NFS client. The simplest way may be parse the file
>> handle to get the file ino and directory ino, but I don't know how to
>> get them from the 64 of 16 hexadecimal. Can you tell me how to parse
>> file handle to get useful information, thanks very much.
>
>That file handle contents are opaque to the client so you'd
>need to have the server's code or reverse engineer its
>structure.
Wireshark understands the format of many NFS server filehandles. You
can simply zoom-in on the filehandle in the details pane to see much of
this. Alternatively, you can look back in the trace to find the LOOKUP
or READDIR/READDIRPLUS to find the mapping between name and
filehandle.
By the way, not all filehandles are 64 bytes. That, too, is a server-specific
choice.
Tom.
On Mon, 2008-05-19 at 07:08 -0400, Talpey, Thomas wrote:
> At 04:56 AM 5/19/2008, Benny Halevy wrote:
> >On May. 19, 2008, 11:14 +0300, xing jing <[email protected]> wrote:
> >> recently, I want to get some information (like file access patten)
> >> from a trace of NFS client. The simplest way may be parse the file
> >> handle to get the file ino and directory ino, but I don't know how to
> >> get them from the 64 of 16 hexadecimal. Can you tell me how to parse
> >> file handle to get useful information, thanks very much.
> >
> >That file handle contents are opaque to the client so you'd
> >need to have the server's code or reverse engineer its
> >structure.
>
> Wireshark understands the format of many NFS server filehandles. You
> can simply zoom-in on the filehandle in the details pane to see much of
> this. Alternatively, you can look back in the trace to find the LOOKUP
> or READDIR/READDIRPLUS to find the mapping between name and
> filehandle.
>
> By the way, not all filehandles are 64 bytes. That, too, is a server-specific
> choice.
...and in Linux it is actually a filesystem-specific choice.
Furthermore, since not all Linux filesystems have permanently stored
inode numbers, many filehandle types don't encode an inode number.
Finally, if you turn off subtree checking (as indeed you should), then
the filehandle doesn't contain a directory inode number.
In other words, parsing filehandles to obtain inode numbers from Linux
servers is not a task that can be easily automated...
Trond
On May 19, 2008, at 7:08 AM, Talpey, Thomas wrote:
> At 04:56 AM 5/19/2008, Benny Halevy wrote:
>> On May. 19, 2008, 11:14 +0300, xing jing <[email protected]> wrote:
>>> recently, I want to get some information (like file access patten)
>>> from a trace of NFS client. The simplest way may be parse the file
>>> handle to get the file ino and directory ino, but I don't know how
>>> to
>>> get them from the 64 of 16 hexadecimal. Can you tell me how to parse
>>> file handle to get useful information, thanks very much.
>>
>> That file handle contents are opaque to the client so you'd
>> need to have the server's code or reverse engineer its
>> structure.
>
> Wireshark understands the format of many NFS server filehandles. You
> can simply zoom-in on the filehandle in the details pane to see much
> of
> this. Alternatively, you can look back in the trace to find the LOOKUP
> or READDIR/READDIRPLUS to find the mapping between name and
> filehandle.
>
> By the way, not all filehandles are 64 bytes. That, too, is a server-
> specific choice.
Wireshark has the ability to sniff filehandles from certain server
types. I believe both Linux server file handles and NetApp file
handles are supported. You need to set this in the preference pane
for the NFS decoder, it won't try to discover which server type you
use automatically. Otherwise it will treat file handles as entirely
opaque.
Also, there is a checkbox in the NFS decoder preference pane for
enabling wireshark to associated file handles with file names and
display the file names where appropriate.
The checkbox is "Snoop FH to filename mappings".
>
>
> Tom.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
At 10:36 AM 5/19/2008, Chuck Lever wrote:
>Also, there is a checkbox in the NFS decoder preference pane for
>enabling wireshark to associated file handles with file names and
>display the file names where appropriate.
>The checkbox is "Snoop FH to filename mappings".
Ooh- didn't know about that one. Cool. It can even build the entire
directory <-> FH tree to show the full pathname, if available.
http://wiki.wireshark.org/NFS_Preferences
Tom.