In Lustre 2 and above, the inode numbers, which on a standard file system represent the static integer ID of a file now appear to be totally insane, being full 64bit integers.

[root@coolermaster lustre]# stat x y z
  File: `x'
  Size: 0               Blocks: 0          IO Block: 4194304 regular empty file
Device: 2c54f966h/743766374d    Inode: 144115238843759750  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-10-08 12:40:26.000000000 -0600
Modify: 2013-10-08 12:40:26.000000000 -0600
Change: 2013-10-08 12:40:26.000000000 -0600
  File: `y'
  Size: 0               Blocks: 0          IO Block: 4194304 regular empty file
Device: 2c54f966h/743766374d    Inode: 144115238843759751  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-10-08 13:23:06.000000000 -0600
Modify: 2013-10-08 13:23:06.000000000 -0600
Change: 2013-10-08 13:23:06.000000000 -0600
  File: `z'
  Size: 0               Blocks: 0          IO Block: 4194304 regular empty file
Device: 2c54f966h/743766374d    Inode: 144115238843759752  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-10-08 13:23:06.000000000 -0600
Modify: 2013-10-08 13:23:06.000000000 -0600

Um.. interesting right? This is on a very small, single node file system with 3 files, and a lifetime total file creation in the tens of thousands, not the hundreds of trillions. After a quick discussion with Green (Oleg Drokin) correctly pointed out that the new inode numbering schema is used to provide FID’s, these are file identifiers unique to Lustre and identify the file uniquely across all nodes.

So mystery solved, and the joy of insane inode sizes now begins.