- <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 Lustre, 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>