<?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_44971"/></para>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438219_84890"/></para>
- </listitem>
- <listitem>
<para><xref linkend="dbdoclet.50438219_90386"/></para>
</listitem>
<listitem>
</section>
<section remap="h5">
<title>Files</title>
- <para>The l_getidentity files are located at:</para>
- <screen>/proc/fs/lustre/mdt/${FSNAME}-MDT{xxxx}/identity_upcall</screen>
+ <para>The parameter to set the <literal>l_getidentity</literal> path is:
+ </para>
+<screen>mds# lctl set_param -P mdt.*-MDT*.identity_upcall=<replaceable>path</replaceable>
+</screen>
</section>
</section>
<section xml:id="dbdoclet.50438219_38274">
</section>
<section remap="h5">
<title>Setting Parameters with lctl</title>
- <para>Lustre parameters are not always accessible using the procfs interface, as it is platform-specific. As a solution, lctl {get,set}_param has been introduced as a platform-independent interface to the Lustre tunables. Avoid direct references to /proc/{fs,sys}/{lustre,lnet}. For future portability, use lctl {get,set}_param .</para>
- <para>When the file system is running, use the <literal>lctl set_param</literal> command on the affected node(s) to <emphasis>temporarily</emphasis> set parameters (mapping to items in /proc/{fs,sys}/{lnet,lustre}). The <literal>lctl set_param</literal> command uses this syntax:</para>
+ <para>Lustre parameters are not always accessible using the procfs
+ interface, as it is platform-specific. As a solution,
+ <literal>lctl {get,set}_param</literal> provides a platform-independent
+ interface to the Lustre tunables. Avoid any direct references to
+ <literal>/proc</literal> and <literal>/sys</literal> files in scripts.
+ For future portability, instead use lctl {get,set}_param, which handles
+ these details internally.</para>
+ <para>When the file system is running, use the
+ <literal>lctl set_param</literal> command on the affected node(s) to
+ <emphasis>temporarily</emphasis> set parameters (mapping to items in).
+ The <literal>lctl set_param</literal> command uses this syntax:</para>
<screen>lctl set_param [-n] [-P] [-d] <replaceable>obdtype.obdname.property</replaceable>=<replaceable>value</replaceable></screen>
<para>For example:</para>
- <screen>mds# lctl set_param mdt.testfs-MDT0000.identity_upcall=NONE</screen>
- <para condition='l25'>Use <literal>-P</literal> option to set parameters permanently. Option <literal>-d </literal>deletes permanent parameters. For example:
- <screen>mgs# lctl set_param -P mdt.testfs-MDT0000.identity_upcall=NONE
+<screen>mds# lctl set_param mdt.testfs-MDT0000.identity_upcall=NONE</screen>
+ <para condition='l25'>Use <literal>-P</literal> option to set parameters
+ permanently. Option <literal>-d </literal>deletes permanent parameters.
+ For example:
+<screen>
+mgs# lctl set_param -P mdt.testfs-MDT0000.identity_upcall=NONE
mgs# lctl set_param -P -d mdt.testfs-MDT0000.identity_upcall</screen></para>
- <para>Many permanent parameters can be set with <literal>lctl conf_param</literal>. In general, <literal>lctl conf_param</literal> can be used to specify any OBD device parameter settable in a /proc/fs/lustre file. The <literal>lctl conf_param</literal> command must be run on the MGS node, and uses this syntax:</para>
+ <para>Many permanent parameters can be set with the
+ <literal>lctl conf_param</literal> utility. In general,
+ <literal>lctl conf_param</literal> can be used to specify any OBD
+ device parameter settable in a /proc/fs/lustre file. The
+ <literal>lctl conf_param</literal> command must be run on the MGS node,
+ and uses this syntax:</para>
<screen><replaceable>obd|fsname</replaceable>.obdtype.property=<replaceable>value</replaceable>) </screen>
<para>For example:</para>
<screen>mgs# lctl conf_param testfs-MDT0000.mdt.identity_upcall=NONE
<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>
online scanning will automatically move objects from
<literal>lost+found</literal> to the proper place in the OST.</para>
</note>
- <note condition='l25'>
- <para>The <literal>ll_recover_lost_found_objs</literal> tool is not
- strictly necessary to bring an OST back online, it just avoids losing
- access to objects that were moved to the lost+found directory due to
- directory corruption on 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>
- </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>
<para>The lustre_req_history.sh utility (run from a client), assembles as much Lustre RPC request history as possible from the local node and from the servers that were contacted, providing a better picture of the coordinated network activity.</para>
</section>
<section remap="h3">
- <title>More /proc Statistics for Application Profiling</title>
+ <title>More Statistics for Application Profiling</title>
<para>The following utilities provide additional statistics.</para>
<para><literal>vfs_ops_stats</literal></para>
- <para>The client vfs_ops_stats utility tracks Linux VFS operation calls into Lustre for a single PID, PPID, GID or everything.</para>
- <screen>/proc/fs/lustre/llite/*/vfs_ops_stats
-/proc/fs/lustre/llite/*/vfs_track_[pid|ppid|gid]
-</screen>
+ <para>The client vfs_ops_stats utility tracks Linux VFS operation calls
+ into Lustre for a single PID, PPID, GID or everything.</para>
+ <screen>llite.*.vfs_ops_stats llite.*.vfs_track_[pid|ppid|gid]</screen>
<para><literal>extents_stats</literal></para>
- <para>The client extents_stats utility shows the size distribution of I/O calls from the client (cumulative and by process).</para>
- <screen>/proc/fs/lustre/llite/*/extents_stats, extents_stats_per_process
-</screen>
+ <para>The client extents_stats utility shows the size distribution of
+ I/O calls from the client (cumulative and by process).</para>
+ <screen>llite.*.{extents_stats,extents_stats_per_process}</screen>
<para><literal>offset_stats</literal></para>
- <para>The client offset_stats utility shows the read/write seek activity of a client by offsets and ranges.</para>
- <screen>/proc/fs/lustre/llite/*/offset_stats
-</screen>
+ <para>The client offset_stats utility shows the read/write seek activity
+ of a client by offsets and ranges.</para>
+ <screen>llite.*.offset_stats</screen>
<para>Lustre includes per-client and improved MDT statistics:</para>
<itemizedlist>
<listitem>
<para>Each MDS and OSS now tracks LDLM and operations statistics for
every connected client, for comparisons and simpler collection of
distributed job statistics.</para>
- <screen>/proc/fs/lustre/mds|obdfilter/*/exports/
+ <screen>{mds,obdfilter}.*.exports
</screen>
<itemizedlist>
<listitem>
</itemizedlist>
<para>More detailed MDT operations statistics are collected for better
profiling.</para>
- <screen>/proc/fs/lustre/mdt/*/md_stats
+ <screen>mdt.*.md_stats
</screen>
</section>
<section remap="h3">
</section>
</section>
</chapter>
+<!--
+ vim:expandtab:shiftwidth=2:tabstop=8:
+ -->
git://git.whamcloud.com / doc / manual.git / blobdiff