* how to parse the 64byte NFSv3 file handle
@ 2008-05-19 8:14 xing jing
[not found] ` <483136FC.4050208-3pZTqkFmMFknDS1+zs4M5A@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: xing jing @ 2008-05-19 8:14 UTC (permalink / raw)
To: linux-nfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: how to parse the 64byte NFSv3 file handle
[not found] ` <483136FC.4050208-3pZTqkFmMFknDS1+zs4M5A@public.gmane.org>
@ 2008-05-19 8:56 ` Benny Halevy
2008-05-19 11:08 ` Talpey, Thomas
0 siblings, 1 reply; 6+ messages in thread
From: Benny Halevy @ 2008-05-19 8:56 UTC (permalink / raw)
To: xing jing; +Cc: linux-nfs
On May. 19, 2008, 11:14 +0300, xing jing <xingjing-3pZTqkFmMFknDS1+zs4M5A@public.gmane.org> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: how to parse the 64byte NFSv3 file handle
2008-05-19 8:56 ` Benny Halevy
@ 2008-05-19 11:08 ` Talpey, Thomas
[not found] ` <RTPCLUEXC1-PRDpAOAk000000fd-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: Talpey, Thomas @ 2008-05-19 11:08 UTC (permalink / raw)
To: xing jing, Benny Halevy; +Cc: linux-nfs
At 04:56 AM 5/19/2008, Benny Halevy wrote:
>On May. 19, 2008, 11:14 +0300, xing jing <xingjing-3pZTqkFmMFknDS1+zs4M5A@public.gmane.org> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: how to parse the 64byte NFSv3 file handle
[not found] ` <RTPCLUEXC1-PRDpAOAk000000fd-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
@ 2008-05-19 14:28 ` Trond Myklebust
2008-05-19 14:36 ` Chuck Lever
1 sibling, 0 replies; 6+ messages in thread
From: Trond Myklebust @ 2008-05-19 14:28 UTC (permalink / raw)
To: Talpey, Thomas; +Cc: xing jing, Benny Halevy, linux-nfs
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 <xingjing-3pZTqkFmMFknDS1+zs4M5A@public.gmane.org> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: how to parse the 64byte NFSv3 file handle
[not found] ` <RTPCLUEXC1-PRDpAOAk000000fd-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-05-19 14:28 ` Trond Myklebust
@ 2008-05-19 14:36 ` Chuck Lever
2008-05-19 14:44 ` Talpey, Thomas
1 sibling, 1 reply; 6+ messages in thread
From: Chuck Lever @ 2008-05-19 14:36 UTC (permalink / raw)
To: xing jing; +Cc: Benny Halevy, Linux NFS Mailing List, Thomas Talpey
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 <xingjing-3pZTqkFmMFknDS1+zs4M5A@public.gmane.org> 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: how to parse the 64byte NFSv3 file handle
2008-05-19 14:36 ` Chuck Lever
@ 2008-05-19 14:44 ` Talpey, Thomas
0 siblings, 0 replies; 6+ messages in thread
From: Talpey, Thomas @ 2008-05-19 14:44 UTC (permalink / raw)
To: Chuck Lever; +Cc: xing jing, Benny Halevy, Linux NFS Mailing List
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-05-19 14:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-19 8:14 how to parse the 64byte NFSv3 file handle xing jing
[not found] ` <483136FC.4050208-3pZTqkFmMFknDS1+zs4M5A@public.gmane.org>
2008-05-19 8:56 ` Benny Halevy
2008-05-19 11:08 ` Talpey, Thomas
[not found] ` <RTPCLUEXC1-PRDpAOAk000000fd-rtwIt2gI0FxT+ZUat5FNkAK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
2008-05-19 14:28 ` Trond Myklebust
2008-05-19 14:36 ` Chuck Lever
2008-05-19 14:44 ` Talpey, Thomas
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.