packet inspection tool that allows debugging of information that was
sent between the various Lustre nodes. This tool is built on top of
<literal>tcpdump</literal> and can read packet dumps generated by
- it. There are plug-ins available to dissassemble the LNET and
+ it. There are plug-ins available to dissassemble the LNet and
Lustre protocols. They are located within the <link
xl:href="http://git.hpdd.intel.com/">Lustre git repository</link>
under <literal>lustre/contrib/wireshark/</literal>. Installation
attributes for a new file or directory.</para>
<para>The <literal>lfs getstripe</literal> command takes a Lustre filename as input and lists
all the objects that form a part of this file. To obtain this information for the file
- <literal>/mnt/lustre/frog</literal> in a Lustre file system, run:</para>
- <screen>$ lfs getstripe /mnt/lustre/frog
+ <literal>/mnt/testfs/frog</literal> in a Lustre file system, run:</para>
+ <screen>$ lfs getstripe /mnt/testfs/frog
lmm_stripe_count: 2
lmm_stripe_size: 1048576
+lmm_pattern: 1
+lmm_layout_gen: 0
lmm_stripe_offset: 2
obdidx objid objid group
2 818855 0xc7ea7 0
0 873123 0xd52a3 0
</screen>
- <para>The <literal>debugfs</literal> tool is provided in the <literal>e2fsprogs</literal>
- package. It can be used for interactive debugging of an <literal>ldiskfs</literal> file
- system. The <literal>debugfs</literal> tool can either be used to check status or modify
- information in the file system. In a Lustre file system, all objects that belong to a file
- are stored in an underlying <literal>ldiskfs</literal> file system on the OSTs. The file
- system uses the object IDs as the file names. Once the object IDs are known, use the
- <literal>debugfs</literal> tool to obtain the attributes of all objects from different
- OSTs.</para>
- <para>A sample run for the <literal>/mnt/lustre/frog</literal> file used in the above example is shown here:</para>
+ <para>The <literal>debugfs</literal> tool is provided in the
+ <literal>e2fsprogs</literal> package. It can be used for interactive
+ debugging of an <literal>ldiskfs</literal> file system. The
+ <literal>debugfs</literal> tool can either be used to check status or
+ modify information in the file system. In a Lustre file system, all
+ objects that belong to a file are stored in an underlying
+ <literal>ldiskfs</literal> file system on the OSTs. The file system
+ uses the object IDs as the file names. Once the object IDs are known,
+ use the <literal>debugfs</literal> tool to obtain the attributes of
+ all objects from different OSTs.</para>
+ <para>A sample run for the <literal>/mnt/testfs/frog</literal> file used
+ in the above example is shown here:</para>
<screen>$ debugfs -c -R "stat O/0/d$((818855 % 32))/818855" /dev/vgmyth/lvmythost2
debugfs 1.41.90.wc3 (28-May-2011)
lctl> show dlmtrace
lctl> debug_kernel [<replaceable>filename</replaceable>] </screen>
</section>
+ <section remap="h3">
+ <title>Controlling Console Message Rate Limiting</title>
+ <para>Some console messages which are printed by Lustre are rate limited. When such messages are printed, they may be followed by a message saying "Skipped N previous similar message(s)," where N is the number of messages skipped. This rate limiting can be completely disabled by a libcfs module parameter called <literal>libcfs_console_ratelimit</literal>. To disable console message rate limiting, add this line to <literal>/etc/modprobe.d/lustre.conf</literal> and then reload Lustre modules.</para>
+ <screen>options libcfs libcfs_console_ratelimit=0</screen>
+ <para>It is also possible to set the minimum and maximum delays between rate-limited console messages using the module parameters <literal>libcfs_console_max_delay</literal> and <literal>libcfs_console_min_delay</literal>. Set these in <literal>/etc/modprobe.d/lustre.conf</literal> and then reload Lustre modules. Additional information on libcfs module parameters is available via <literal>modinfo</literal>:</para>
+ <screen>modinfo libcfs</screen>
+ </section>
</section>
<section xml:id="dbdoclet.50438274_80443">
<title><indexterm><primary>debugging</primary><secondary>developers tools</secondary></indexterm>Lustre Debugging for Developers</title>
</emphasis></para>
</entry>
<entry>
- <para> Behaves similarly to <literal>CERROR()</literal>, but prints error messages for LNET if <literal>D_NETERR</literal> is set in the <literal>debug</literal> mask. This is appropriate for serious networking errors. Messages printed to the console are rate-limited.</para>
+ <para> Behaves similarly to <literal>CERROR()</literal>, but prints error messages for LNet if <literal>D_NETERR</literal> is set in the <literal>debug</literal> mask. This is appropriate for serious networking errors. Messages printed to the console are rate-limited.</para>
</entry>
</row>
<row>
<section remap="h3">
<title>Accessing the <literal>ptlrpc</literal> Request History</title>
<para>Each service maintains a request history, which can be useful for first occurrence troubleshooting.</para>
- <para><literal>ptlrpc</literal> is an RPC protocol layered on LNET that deals with stateful servers and has semantics and built-in support for recovery.</para>
+ <para><literal>ptlrpc</literal> is an RPC protocol layered on LNet that deals with stateful servers and has semantics and built-in support for recovery.</para>
<para>The ptlrpc request history works as follows:</para>
<orderedlist>
<listitem>
git://git.whamcloud.com / doc / manual.git / blobdiff