- <title><indexterm>
- <primary>Lustre</primary>
- <secondary>storage</secondary>
- </indexterm>
- <indexterm>
- <primary>Lustre</primary>
- <secondary>I/O</secondary>
- </indexterm> Lustre Storage and I/O</title>
- <para>In a Lustre file system, a file stored on the MDT points to one or more objects associated
- with a data file, as shown in <xref linkend="understandinglustre.fig.mdtost"/>. Each object
- contains data and is stored on an OST. If the MDT file points to one object, all the file data
- is stored in that object. If the file points to more than one object, the file data is
- 'striped' across the objects (using RAID 0) and each object is stored on a different
- OST. (For more information about how striping is implemented in a Lustre file system, see
- <xref linkend="dbdoclet.50438250_89922"/>)</para>
- <para>In <xref linkend="understandinglustre.fig.mdtost"/>, each filename points to an inode. The
- inode contains all of the file attributes, such as owner, access permissions, Lustre striping
- layout, access time, and access control. Multiple filenames may point to the same
- inode.</para>
- <figure>
- <title xml:id="understandinglustre.fig.mdtost">MDT file points to objects on OSTs containing
- file data</title>
+ <title>
+ <indexterm>
+ <primary>Lustre</primary>
+ <secondary>storage</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>Lustre</primary>
+ <secondary>I/O</secondary>
+ </indexterm>Lustre File System Storage and I/O</title>
+ <para>In Lustre software release 2.0, Lustre file identifiers (FIDs) were
+ introduced to replace UNIX inode numbers for identifying files or objects.
+ A FID is a 128-bit identifier that contains a unique 64-bit sequence
+ number, a 32-bit object ID (OID), and a 32-bit version number. The sequence
+ number is unique across all Lustre targets in a file system (OSTs and
+ MDTs). This change enabled future support for multiple MDTs (introduced in
+ Lustre software release 2.4) and ZFS (introduced in Lustre software release
+ 2.4).</para>
+ <para>Also introduced in release 2.0 is an ldiskfs feature named
+ <emphasis role="italic">FID-in-dirent</emphasis>(also known as
+ <emphasis role="italic">dirdata</emphasis>) in which the FID is stored as
+ part of the name of the file in the parent directory. This feature
+ significantly improves performance for
+ <literal>ls</literal> command executions by reducing disk I/O. The
+ FID-in-dirent is generated at the time the file is created.</para>
+ <note>
+ <para>The FID-in-dirent feature is not backward compatible with the
+ release 1.8 ldiskfs disk format. Therefore, when an upgrade from
+ release 1.8 to release 2.x is performed, the FID-in-dirent feature is
+ not automatically enabled. For upgrades from release 1.8 to releases
+ 2.0 through 2.3, FID-in-dirent can be enabled manually but only takes
+ effect for new files.</para>
+ <para>For more information about upgrading from Lustre software release
+ 1.8 and enabling FID-in-dirent for existing files, see
+ <xref xmlns:xlink="http://www.w3.org/1999/xlink"
+ linkend="upgradinglustre" />Chapter 16 “Upgrading a Lustre File
+ System”.</para>
+ </note>
+ <para condition="l24">The LFSCK file system consistency checking tool
+ released with Lustre software release 2.4 provides functionality that
+ enables FID-in-dirent for existing files. It includes the following
+ functionality:
+ <itemizedlist>
+ <listitem>
+ <para>Generates IGIF mode FIDs for existing files from a 1.8 version
+ file system files.</para>
+ </listitem>
+ <listitem>
+ <para>Verifies the FID-in-dirent for each file and regenerates the
+ FID-in-dirent if it is invalid or missing.</para>
+ </listitem>
+ <listitem>
+ <para>Verifies the linkEA entry for each and regenerates the linkEA
+ if it is invalid or missing. The
+ <emphasis role="italic">linkEA</emphasis> consists of the file name and
+ parent FID. It is stored as an extended attribute in the file
+ itself. Thus, the linkEA can be used to reconstruct the full path name
+ of a file.</para>
+ </listitem>
+ </itemizedlist></para>
+ <para>Information about where file data is located on the OST(s) is stored
+ as an extended attribute called layout EA in an MDT object identified by
+ the FID for the file (see
+ <xref xmlns:xlink="http://www.w3.org/1999/xlink"
+ linkend="Fig1.3_LayoutEAonMDT" />). If the file is a regular file (not a
+ directory or symbol link), the MDT object points to 1-to-N OST object(s) on
+ the OST(s) that contain the file data. If the MDT file points to one
+ object, all the file data is stored in that object. If the MDT file points
+ to more than one object, the file data is
+ <emphasis role="italic">striped</emphasis> across the objects using RAID 0,
+ and each object is stored on a different OST. (For more information about
+ how striping is implemented in a Lustre file system, see
+ <xref linkend="dbdoclet.50438250_89922" />.</para>
+ <figure xml:id="Fig1.3_LayoutEAonMDT">
+ <title>Layout EA on MDT pointing to file data on OSTs</title>