Ahh, clears up quit a few things. SO, two more questions :
1) Where/how would I "turn on the 'nfs.big_endianize_fileid'" ?
2) Is there a way of converting the numbers without having to do it by hand?
On Thu, 13 May 1999, Guy Harris wrote:
**2) NetApp's doc states that the second number is the device number of the file system,
NetApp's doc is full of prunes. I'll have to go yell at whoever wrote it. We don't have device numbers in the "dev_t" sense....
and the third number is the inode number. NO, the 3rd number is "0".
File handles in pre-5.0 releases consist of:
32-bit file ID for mount point 32-bit generation count for mount point 16-bit set of flags for file 8-bit snapshot ID in which file resides 8-bit unused byte 32-bit file ID for file 32-bit generation count for file 16-bit set of flags for export point 8-bit snapshot ID in which export point resides 8-bit unused byte 32-bit file ID for export point 32-bit generation count for export point
where "mount point" is the file or directory the client mounted, and "export point" is the exported file or directory that file or directory is or resides under.
All numbers are *little-endian*, as the processors on filers are little-endian, unless you turn on the "nfs.big_endianize_fileid" option to compensate for NFS clients that hash internal data structures based on a part of the file handle likely to be zero if the file's file ID is little-endian, in which case the file's file ID (but not the export point's file ID or the mount point's file ID) are big-endian.
So that file handle is:
939e1400 mount point file ID: 0x00149E93, or 1351315 577cd30c mount point generation count: 0x0CD37C57, or 215186519 0 file flags, snapshot ID, unused 856f1000 file ID: 0x00106F85, or 1077125 49ee7326 generation count: 0x2673EE49, or 645131849 0 export point flags, snapshot ID, unused 2ae0500 export point file ID: 0x0005AE02, or 372226 51356400 export point generation count: 0x00643551, or 6567249
In 5.0, we had to add a file system ID; file handles in 5.0 and later consist of:
32-bit file ID for mount point 32-bit generation count for mount point 8-bit snapshot ID in which file resides 8-bit unused byte 32-bit file ID for file 32-bit generation count for file 32-bit volume ID for file 32-bit file ID for export point 32-bit combined snapshot ID and generation number for export point; the upper 8 bits of that 32-bit quantity are the snapshot ID and the lower 24 bits are the generation number.
The file's file ID (but not the mount point's or export point's file ID) is *big-endian*; one of the flags lets the filer tell old-format from new-format file handles, so we can send back old-format file handles in response to requests that have old-format file handles, as clients can get quite confused if they get two different file handles for the same file (yes, that really happens with many, perhaps most, UNIX clients, as they allocate two different internal data structures of the type mentioned above - "rnodes" - for the two different file handles, and thus they don't realize that they're the same file).
My guess is that the filer uses a 64bit INODE number,
Nope, 32 bits.
----------- Fujitsu - Nexion, St. Louis, MO Jay Orr (314) 579-6517