LUDOC-479 lnet: Clarify transmit and routing credits

[doc/manual.git] / LustreTroubleshooting.xml

diff --git a/LustreTroubleshooting.xml b/LustreTroubleshooting.xml
index 69cffe4..b82c558 100644 (file)
--- a/LustreTroubleshooting.xml
+++ b/LustreTroubleshooting.xml
@@ -1,4 +1,7 @@
-<?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="lustretroubleshooting">
+<?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="lustretroubleshooting">
   <title xml:id="lustretroubleshooting.title">Lustre File System Troubleshooting</title>
   <para>This chapter provides information about troubleshooting a Lustre file system, submitting a
     bug to the Jira bug tracking system, and Lustre file system performance tips. It includes the
@@ -201,7 +204,8 @@
           <para>Which server node it was communicating with, and so on.</para>
         </listitem>
       </itemizedlist>
-      <para>Lustre logs are dumped to <literal>/proc/sys/lnet/debug_path</literal>.</para>
+      <para>Lustre logs are dumped to the pathname stored in the parameter
+      <literal>lnet.debug_path</literal>.</para>
       <para>Collect the first group of messages related to a problem, and any messages that precede &quot;LBUG&quot; or &quot;assertion failure&quot; errors. Messages that mention server nodes (OST or MDS) are specific to that server; you must collect similar messages from the relevant server console logs.</para>
       <para>Another Lustre debug log holds information for a short period of time for action by the
         Lustre software, which, in turn, depends on the processes on the Lustre node. Use the
@@ -373,7 +377,7 @@
       <para>If the SCSI devices are inaccessible to the Lustre file system
         at the block device level, then <literal>ldiskfs</literal> remounts
         the device read-only to prevent file system corruption. This is a normal
-        behavior. The status in <literal>/proc/fs/lustre/health_check</literal>
+        behavior. The status in the parameter <literal>health_check</literal>
         also shows &quot;not healthy&quot; on the affected nodes.</para>
       <para>To determine what caused the &quot;not healthy&quot; condition:</para>
       <itemizedlist>
@@ -745,7 +749,8 @@ server now claims 791)!
           <para> Lustre or kernel stack traces showing processes stuck in &quot;<literal>try_to_free_pages</literal>&quot;</para>
         </listitem>
       </itemizedlist>
-      <para>For information on determining the MDS memory and OSS memory requirements, see <xref linkend="dbdoclet.50438256_26456"/>.</para>
+      <para>For information on determining the MDS memory and OSS memory
+      requirements, see <xref linkend="dbdoclet.mds_oss_memory"/>.</para>
     </section>
     <section remap="h3">
       <title>Setting SCSI I/O Sizes</title>
@@ -764,3 +769,6 @@ server now claims 791)!
     </section>
   </section>
 </chapter>
+<!--
+  vim:expandtab:shiftwidth=2:tabstop=8:
+  -->