<?xml version='1.0' encoding='UTF-8'?>
-<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US" xml:id="systemconfigurationutilities">
+<chapter xmlns="http://docbook.org/ns/docbook"
+ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US"
+ xml:id="systemconfigurationutilities">
<title xml:id="systemconfigurationutilities.title">System Configuration Utilities</title>
<para>This chapter includes system configuration utilities and includes the following sections:</para>
<itemizedlist>
<para><xref linkend="dbdoclet.50438219_55923"/></para>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438219_76969"/></para>
+ <para><xref linkend="dbdoclet.l_getidentity"/></para>
</listitem>
<listitem>
<para><xref linkend="dbdoclet.50438219_38274"/></para>
<para><xref linkend="dbdoclet.50438219_44971"/></para>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438219_84890"/></para>
- </listitem>
- <listitem>
<para><xref linkend="dbdoclet.50438219_90386"/></para>
</listitem>
<listitem>
<title><indexterm><primary>e2scan</primary></indexterm>
e2scan</title>
<para>The e2scan utility is an ext2 file system-modified inode scan program. The e2scan program uses libext2fs to find inodes with ctime or mtime newer than a given time and prints out their pathname. Use e2scan to efficiently generate lists of files that have been modified. The e2scan tool is included in the e2fsprogs package, located at:</para>
- <para><link xl:href="http://downloads.hpdd.intel.com/public/e2fsprogs/latest/">http://downloads.hpdd.intel.com/public/e2fsprogs/latest/</link></para>
+ <para><link xl:href="http://downloads.whamcloud.com/public/e2fsprogs/latest/">http://downloads.whamcloud.com/public/e2fsprogs/latest/</link></para>
<section remap="h5">
<title>Synopsis</title>
<screen>e2scan [options] [-f file] block_device</screen>
</informaltable>
</section>
</section>
- <section xml:id="dbdoclet.50438219_76969">
+ <section xml:id="dbdoclet.l_getidentity">
<title><indexterm><primary>l_getidentity</primary></indexterm>
l_getidentity</title>
- <para>The l_getidentity utility handles Lustre user / group cache upcall.</para>
+ <para>The l_getidentity tool normally handles Lustre user/group mapping
+ upcall.</para>
<section remap="h5">
<title>Synopsis</title>
- <screen>l_getidentity ${FSNAME}-MDT{xxxx} {uid}</screen>
+ <screen>l_getidentity { $FSNAME-MDT{xxxx}| -d} {uid}</screen>
</section>
<section remap="h5">
<title>Description</title>
- <para>The group upcall file contains the path to an executable file that is invoked to resolve
- a numeric UID to a group membership list. This utility opens
- <literal>/proc/fs/lustre/mdt/${FSNAME}-MDT{xxxx}/identity_info</literal> and writes the
- related <literal>identity_downcall_data</literal> structure (see <xref
- linkend="dbdoclet.50438291_33759"/>.) The data is persisted with <literal>lctl set_param
- mdt.${FSNAME}-MDT{xxxx}.identity_info</literal>.</para>
- <para>The l_getidentity utility is the reference implementation of the user or group cache upcall.</para>
+ <para>The <literal>l_getidentity</literal> utility is called from the
+ MDS to map a numeric UID value into the list of supplementary group
+ values for that UID, and writes this into the
+ <literal>mdt.*.identity_info</literal> parameter file. The list of
+ supplementary groups is cached in the kernel to avoid repeated
+ upcalls. See <xref linkend="dbdoclet.identity_upcall"/> for more
+ details.</para>
+ <para>The <literal>l_getidentity</literal> utility can also be run
+ directly for debugging purposes to ensure that the UID mapping for a
+ particular user is configured correctly, by using the
+ <literal>-d</literal> argument instead of the MDT name.
+ </para>
</section>
<section remap="h5">
<title>Options</title>
<tbody>
<row>
<entry>
- <para> <literal>network up|down|tcp|elan|myrinet</literal></para>
+ <para> <literal>network up|down|tcp|elan</literal></para>
</entry>
<entry>
<para> Starts or stops LNet, or selects a network type for other <literal>lctl</literal> LNet commands.</para>
<section xml:id="dbdoclet.50438219_58217">
<title><indexterm><primary>ll_decode_filter_fid</primary></indexterm>
ll_decode_filter_fid</title>
- <para>The ll_decode_filter_fid utility displays the Lustre object ID and MDT parent FID.</para>
+ <para>The <literal>ll_decode_filter_fid</literal> utility displays the
+ Lustre object ID and MDT parent FID.</para>
<section remap="h5">
<title>Synopsis</title>
<screen>ll_decode_filter_fid object_file [object_file ...]</screen>
</section>
<section remap="h5">
<title>Description</title>
- <para>The ll_decode_filter_fid utility decodes and prints the Lustre OST object ID, MDT FID,
- stripe index for the specified OST object(s), which is stored in the "trusted.fid"
- attribute on each OST object. This is accessible to <literal>ll_decode_filter_fid</literal>
- when the OST file system is mounted locally as type ldiskfs for maintenance.</para>
- <para>The "trusted.fid" extended attribute is stored on each OST object when it is first modified (data written or attributes set), and is not accessed or modified by Lustre after that time.</para>
- <para>The OST object ID (objid) is useful in case of OST directory corruption, though normally the ll_recover_lost_found_objs(8) utility is able to reconstruct the entire OST object directory hierarchy. The MDS FID can be useful to determine which MDS inode an OST object is (or was) used by. The stripe index can be used in conjunction with other OST objects to reconstruct the layout of a file even if the MDT inode was lost.</para>
+ <para>The ll_decode_filter_fid utility decodes and prints the Lustre OST
+ object ID, MDT FID, stripe index for the specified OST object(s), which
+ is stored in the "trusted.fid" attribute on each OST object.
+ This is accessible to <literal>ll_decode_filter_fid</literal> when the
+ OST file system is mounted locally as type ldiskfs for maintenance.
+ </para>
+ <para>The "trusted.fid" extended attribute is stored on each
+ OST object when it is first modified (data written or attributes set),
+ and is not accessed or modified by Lustre after that time.</para>
+ <para>The OST object ID (objid) may be useful in case of OST directory
+ corruption, though LFSCK can normally reconstruct the entire OST object
+ directory tree, see <xref linkend="dbdoclet.lfsckadmin" /> for details.
+ The MDS FID can be useful to determine which MDS inode an OST object
+ is (or was) used by. The stripe index can be used in conjunction with
+ other OST objects to reconstruct the layout of a file even if the MDT
+ inode was lost.
+ </para>
</section>
<section remap="h5">
<title>Examples</title>
<para><xref linkend="dbdoclet.50438219_44971"/></para>
</section>
</section>
- <section xml:id="dbdoclet.50438219_44971">
+ <section xml:id="dbdoclet.50438219_44971" condition='l28'>
<title><indexterm><primary>ll_recover_lost_found_objs</primary></indexterm>
ll_recover_lost_found_objs</title>
- <para>The ll_recover_lost_found_objs utility helps recover Lustre OST objects (file data) from a lost and found directory and return them to their correct locations.</para>
- <note>
- <para>Running the ll_recover_lost_found_objs tool is not strictly necessary to bring an OST back online, it just avoids losing access to objects that were moved to the lost and found directory due to directory corruption.</para>
+ <para>The <literal>ll_recover_lost_found_objs</literal> utility was
+ used to help recover Lustre OST objects (file data) from the
+ <literal>lost+found</literal> directory of an OST and return them to
+ their correct locations based on information stored in the
+ <literal>trusted.fid</literal> extended attribute stored on every
+ OST object containing data.</para>
+ <note condition="l26"><para>This utility is not needed with Lustre 2.6
+ and later, and is removed in Lustre 2.8 since <literal>LFSCK</literal>
+ online scanning will automatically move objects from
+ <literal>lost+found</literal> to the proper place in the OST.</para>
</note>
<section remap="h5">
<title>Synopsis</title>
- <screen>$ ll_recover_lost_found_objs [-hv] -d directory</screen>
- </section>
- <section remap="h5">
- <title>Description</title>
- <para>The first time Lustre modifies an object, it saves the MDS inode number and the objid as an extended attribute on the object, so in case of directory corruption of the OST, it is possible to recover the objects. Running e2fsck fixes the corrupted OST directory, but it puts all of the objects into a lost and found directory, where they are inaccessible to Lustre. Use the ll_recover_lost_found_objs utility to recover all (or at least most) objects from a lost and found directory and return them to the O/0/d* directories.</para>
- <para>To use ll_recover_lost_found_objs, mount the file system locally (using the <literal>-t ldiskfs</literal>, or <literal>-t zfs</literal> command), run the utility and then unmount it again. The OST must not be mounted by Lustre when ll_recover_lost_found_objs is run.</para>
- <para condition="l26">This utility is not needed for 2.6 and later,
- since the <literal>LFSCK</literal> online scanning will move objects
- from <literal>lost+found</literal> to the proper place in the OST.</para>
- </section>
- <section remap="h5">
- <title>Options</title>
- <informaltable frame="all">
- <tgroup cols="2">
- <colspec colname="c1" colwidth="50*"/>
- <colspec colname="c2" colwidth="50*"/>
- <thead>
- <row>
- <entry>
- <para><emphasis role="bold">Option</emphasis></para>
- </entry>
- <entry>
- <para><emphasis role="bold">Description</emphasis></para>
- </entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>
- <para> <literal>-h</literal></para>
- </entry>
- <entry>
- <para> Prints a help message</para>
- </entry>
- </row>
- <row>
- <entry>
- <para> <literal>-v</literal></para>
- </entry>
- <entry>
- <para> Increases verbosity</para>
- </entry>
- </row>
- <row>
- <entry>
- <para> <literal>-d <replaceable>directory</replaceable></literal></para>
- </entry>
- <entry>
- <para> Sets the lost and found directory path</para>
- </entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- <section remap="h5">
- <title>Example</title>
- <screen>ll_recover_lost_found_objs -d /mnt/ost/lost+found </screen>
- </section>
- </section>
- <section xml:id="dbdoclet.50438219_84890">
- <title><indexterm><primary>llodbstat</primary></indexterm>
-llobdstat</title>
- <para>The llobdstat utility displays OST statistics.</para>
- <section remap="h5">
- <title>Synopsis</title>
<screen>llobdstat ost_name [interval]</screen>
</section>
<section remap="h5">
<para> <literal>user_fid2path</literal></para>
</entry>
<entry>
- <para condition='l23'>Enable FID to path translation by regular
- users. Note: This option allows a potential security hole
- because it allows regular users direct access to a file by its
- File ID, bypassing POSIX path-based permission checks which
- could otherwise prevent the user from accessing a file in a
- directory that they do not have access to. Regular permission
- checks are still performed on the file itself, so the user
- cannot access a file to which they have no access rights.
- </para>
+ <para>Enable FID-to-path translation by regular users.
+ </para>
+ <note><para>This option allows a potential security hole because
+ it allows regular users direct access to a file by its Lustre
+ File ID. This bypasses POSIX path-based permission checks,
+ and could allow the user to access a file in a directory that
+ they do not have access to. Regular POSIX file mode and ACL
+ permission checks are still performed on the file itself, so
+ users cannot access a file to which they have no permission.
+ </para></note>
</entry>
</row>
<row>
<para> <literal>nouser_fid2path</literal></para>
</entry>
<entry>
- <para condition='l23'> Disable FID to path translation by
+ <para> Disable FID to path translation by
regular users. Root and processes with
<literal>CAP_DAC_READ_SEARCH</literal> can still perform FID
to path translation.
<para> <literal>max_sectors_kb=<replaceable>KB</replaceable></literal></para>
</entry>
<entry>
- <para condition='l210'>Sets the block device parameter
+ <para condition='l2A'>Sets the block device parameter
<literal>max_sectors_kb</literal> limit for the MDT or OST
target being mounted to specified maximum number of kilobytes.
When <literal>max_sectors_kb</literal> isn't specified as a
<para>The stats-collect utility contains scripts used to collect application profiling information from Lustre clients and servers.</para>
</section>
</section>
- <section remap="h3" condition='l29'>
+ <section remap="h3" condition='l29' xml:id="SystemConfigurationUtilities.fileset">
<title><indexterm><primary>fileset</primary></indexterm>Fileset Feature</title>
<para> With the fileset feature, Lustre now provides subdirectory mount
support. Subdirectory mounts, also referred to as filesets, allow a
</section>
</section>
</chapter>
+<!--vim:expandtab:shiftwidth=2:tabstop=8:-->
git://git.whamcloud.com / doc / manual.git / blobdiff