- <para>In order to allow the file system namespace to scale for future applications, Lustre
- software release 2.x internally uses a 128-bit file identifier for all files. To interface
- with user applications, the Lustre software presents 64-bit inode numbers for the
- <literal>stat()</literal>, <literal>fstat()</literal>, and <literal>readdir()</literal>
- system calls on 64-bit applications, and 32-bit inode numbers to 32-bit applications.</para>
- <para>Some 32-bit applications accessing Lustre file systems (on both 32-bit and 64-bit CPUs)
- may experience problems with the <literal>stat()</literal>, <literal>fstat()</literal>
- or<literal> readdir()</literal> system calls under certain circumstances, though the
- Lustre client should return 32-bit inode numbers to these applications.</para>
- <para>In particular, if the Lustre file system is exported from a 64-bit client via NFS to a
- 32-bit client, the Linux NFS server will export 64-bit inode numbers to applications running
- on the NFS client. If the 32-bit applications are not compiled with Large File Support
- (LFS), then they return <literal>EOVERFLOW</literal> errors when accessing the Lustre files.
- To avoid this problem, Linux NFS clients can use the kernel command-line option
- "<literal>nfs.enable_ino64=0</literal>" in order to force the NFS client to
- export 32-bit inode numbers to the client.</para>
- <para><emphasis role="bold">Workaround</emphasis>: We very strongly recommend that backups using <literal>tar(1)</literal> and other utilities that depend on the inode number to uniquely identify an inode to be run on 64-bit clients. The 128-bit Lustre file identifiers cannot be uniquely mapped to a 32-bit inode number, and as a result these utilities may operate incorrectly on 32-bit clients.</para>
+ <para>In order to allow the file system namespace to scale for future
+ applications, Lustre software release 2.x internally uses a 128-bit file
+ identifier for all files. To interface with user applications, the Lustre
+ software presents 64-bit inode numbers for the
+ <literal>stat()</literal>,
+ <literal>fstat()</literal>, and
+ <literal>readdir()</literal> system calls on 64-bit applications, and
+ 32-bit inode numbers to 32-bit applications.</para>
+ <para>Some 32-bit applications accessing Lustre file systems (on both
+ 32-bit and 64-bit CPUs) may experience problems with the
+ <literal>stat()</literal>,
+ <literal>fstat()</literal> or
+ <literal>readdir()</literal> system calls under certain circumstances,
+ though the Lustre client should return 32-bit inode numbers to these
+ applications.</para>
+ <para>In particular, if the Lustre file system is exported from a 64-bit
+ client via NFS to a 32-bit client, the Linux NFS server will export
+ 64-bit inode numbers to applications running on the NFS client. If the
+ 32-bit applications are not compiled with Large File Support (LFS), then
+ they return
+ <literal>EOVERFLOW</literal> errors when accessing the Lustre files. To
+ avoid this problem, Linux NFS clients can use the kernel command-line
+ option "
+ <literal>nfs.enable_ino64=0</literal>" in order to force the NFS client
+ to export 32-bit inode numbers to the client.</para>
+ <para>
+ <emphasis role="bold">Workaround</emphasis>: We very strongly recommend
+ that backups using
+ <literal>tar(1)</literal> and other utilities that depend on the inode
+ number to uniquely identify an inode to be run on 64-bit clients. The
+ 128-bit Lustre file identifiers cannot be uniquely mapped to a 32-bit
+ inode number, and as a result these utilities may operate incorrectly on
+ 32-bit clients.</para>