LustreTuning.xml

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <article version="5.0" xml:lang="en-US" xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink">
   3   <info>
   4     <title>Lustre Tuning</title>
   5   </info>
   6   <informaltable frame="none">
   7     <tgroup cols="2">
   8       <colspec colname="c1" colwidth="50*"/>
   9       <colspec colname="c2" colwidth="50*"/>
  10
  11
  12       <tbody>
  13         <row>
  14           <entry align="left"><para>Lustre 2.0 Operations Manual</para></entry>
  15           <entry align="right" valign="top"><para><link xl:href="index.html"><inlinemediaobject><imageobject role="html">
  16                     <imagedata contentdepth="26" contentwidth="30" fileref="./shared/toc01.gif" scalefit="1"/>
  17                   </imageobject>
  18 <imageobject role="fo">
  19                     <imagedata contentdepth="100%" contentwidth="" depth="" fileref="./shared/toc01.gif" scalefit="1" width="100%"/>
  20                   </imageobject>
  21 </inlinemediaobject></link><link xl:href="BenchmarkingTests.html"><inlinemediaobject><imageobject role="html">
  22                     <imagedata contentdepth="26" contentwidth="30" fileref="./shared/prev01.gif" scalefit="1"/>
  23                   </imageobject>
  24 <imageobject role="fo">
  25                     <imagedata contentdepth="100%" contentwidth="" depth="" fileref="./shared/prev01.gif" scalefit="1" width="100%"/>
  26                   </imageobject>
  27 </inlinemediaobject></link><link xl:href="V_LustreTroubleshooting.html"><inlinemediaobject><imageobject role="html">
  28                     <imagedata contentdepth="26" contentwidth="30" fileref="./shared/next01.gif" scalefit="1"/>
  29                   </imageobject>
  30 <imageobject role="fo">
  31                     <imagedata contentdepth="100%" contentwidth="" depth="" fileref="./shared/next01.gif" scalefit="1" width="100%"/>
  32                   </imageobject>
  33 </inlinemediaobject></link><link xl:href="ix.html"><inlinemediaobject><imageobject role="html">
  34                     <imagedata contentdepth="26" contentwidth="30" fileref="./shared/index01.gif" scalefit="1"/>
  35                   </imageobject>
  36 <imageobject role="fo">
  37                     <imagedata contentdepth="100%" contentwidth="" depth="" fileref="./shared/index01.gif" scalefit="1" width="100%"/>
  38                   </imageobject>
  39 </inlinemediaobject></link></para></entry>
  40         </row>
  41       </tbody>
  42     </tgroup>
  43   </informaltable>
  44   <para><link xl:href=""/></para>
  45   <informaltable frame="none">
  46     <tgroup cols="1">
  47       <colspec colname="c1" colwidth="100*"/>
  48
  49       <tbody>
  50         <row>
  51           <entry align="right"><para><anchor xml:id="dbdoclet.50438272_pgfId-874" xreflabel=""/>C H A P T E R  25<anchor xml:id="dbdoclet.50438272_56727" xreflabel=""/></para></entry>
  52         </row>
  53       </tbody>
  54     </tgroup>
  55   </informaltable>
  56   <informaltable frame="none">
  57     <tgroup cols="1">
  58       <colspec colname="c1" colwidth="100*"/>
  59
  60       <tbody>
  61         <row>
  62           <entry align="right"><para><anchor xml:id="dbdoclet.50438272_pgfId-5529" xreflabel=""/><anchor xml:id="dbdoclet.50438272_66186" xreflabel=""/>Lustre Tuning</para></entry>
  63         </row>
  64       </tbody>
  65     </tgroup>
  66   </informaltable>
  67   <para><anchor xml:id="dbdoclet.50438272_pgfId-1291087" xreflabel=""/>This chapter contains information about tuning Lustre for better performance and includes the following sections:</para>
  68   <itemizedlist><listitem>
  69       <para><anchor xml:id="dbdoclet.50438272_pgfId-1291091" xreflabel=""/><link xl:href="LustreTuning.html#50438272_55226">Optimizing the Number of Service Threads</link></para>
  70     </listitem>
  71 <listitem>
  72       <para> </para>
  73     </listitem>
  74 <listitem>
  75       <para><anchor xml:id="dbdoclet.50438272_pgfId-1294213" xreflabel=""/><link xl:href="LustreTuning.html#50438272_73839">Tuning LNET Parameters</link></para>
  76     </listitem>
  77 <listitem>
  78       <para> </para>
  79     </listitem>
  80 <listitem>
  81       <para><anchor xml:id="dbdoclet.50438272_pgfId-1294288" xreflabel=""/><link xl:href="LustreTuning.html#50438272_25884">Lockless I/O Tunables</link></para>
  82     </listitem>
  83 <listitem>
  84       <para> </para>
  85     </listitem>
  86 <listitem>
  87       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295922" xreflabel=""/><link xl:href="LustreTuning.html#50438272_80545">Improving Lustre Performance When Working with Small Files</link></para>
  88     </listitem>
  89 <listitem>
  90       <para> </para>
  91     </listitem>
  92 <listitem>
  93       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295927" xreflabel=""/><link xl:href="LustreTuning.html#50438272_45406">Understanding Why Write Performance Is Better Than Read Performance</link></para>
  94     </listitem>
  95 <listitem>
  96       <para> </para>
  97     </listitem>
  98 </itemizedlist>
  99   <informaltable frame="none">
 100     <tgroup cols="1">
 101       <colspec colname="c1" colwidth="100*"/>
 102       <tbody>
 103         <row>
 104           <entry><para><emphasis role="bold">Note -</emphasis><anchor xml:id="dbdoclet.50438272_pgfId-1295636" xreflabel=""/>Many options in Lustre are set by means of kernel module parameters. These parameters are contained in the modprobe.conf file.</para></entry>
 105         </row>
 106       </tbody>
 107     </tgroup>
 108   </informaltable>
 109   <section remap="h2">
 110     <title><anchor xml:id="dbdoclet.50438272_pgfId-1291114" xreflabel=""/></title>
 111     <section remap="h2">
 112       <title>25.1 <anchor xml:id="dbdoclet.50438272_55226" xreflabel=""/>Optimizing the Number of Service Threads</title>
 113       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295659" xreflabel=""/>An OSS can have a minimum of 2 service threads and a maximum of 512 service threads. The number of service threads is a function of how much RAM and how many CPUs are on each OSS node (1 thread / 128MB * num_cpus). If the load on the OSS node is high, new service threads will be started in order to process more requests concurrently, up to 4x the initial number of threads (subject to the maximum of 512). For a 2GB 2-CPU system, the default thread count is 32 and the maximum thread count is 128.</para>
 114       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295660" xreflabel=""/>Increasing the size of the thread pool may help when:</para>
 115       <itemizedlist><listitem>
 116           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295661" xreflabel=""/> Several OSTs are exported from a single OSS</para>
 117         </listitem>
 118 <listitem>
 119           <para> </para>
 120         </listitem>
 121 <listitem>
 122           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295662" xreflabel=""/> Back-end storage is running synchronously</para>
 123         </listitem>
 124 <listitem>
 125           <para> </para>
 126         </listitem>
 127 <listitem>
 128           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295663" xreflabel=""/> I/O completions take excessive time due to slow storage</para>
 129         </listitem>
 130 <listitem>
 131           <para> </para>
 132         </listitem>
 133 </itemizedlist>
 134       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295664" xreflabel=""/>Decreasing the size of the thread pool may help if:</para>
 135       <itemizedlist><listitem>
 136           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295665" xreflabel=""/> Clients are overwhelming the storage capacity</para>
 137         </listitem>
 138 <listitem>
 139           <para> </para>
 140         </listitem>
 141 <listitem>
 142           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295666" xreflabel=""/> There are lots of &quot;slow I/O&quot; or similar messages</para>
 143         </listitem>
 144 <listitem>
 145           <para> </para>
 146         </listitem>
 147 </itemizedlist>
 148       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295667" xreflabel=""/>Increasing the number of I/O threads allows the kernel and storage to aggregate many writes together for more efficient disk I/O. The OSS thread pool is shared--each thread allocates approximately 1.5 MB (maximum RPC size + 0.5 MB) for internal I/O buffers.</para>
 149       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295668" xreflabel=""/>It is very important to consider memory consumption when increasing the thread pool size. Drives are only able to sustain a certain amount of parallel I/O activity before performance is degraded, due to the high number of seeks and the OST threads just waiting for I/O. In this situation, it may be advisable to decrease the load by decreasing the number of OST threads.</para>
 150       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295669" xreflabel=""/>Determining the optimum number of OST threads is a process of trial and error, and varies for each particular configuration. Variables include the number of OSTs on each OSS, number and speed of disks, RAID configuration, and available RAM. You may want to start with a number of OST threads equal to the number of actual disk spindles on the node. If you use RAID, subtract any dead spindles not used for actual data (e.g., 1 of N of spindles for RAID5, 2 of N spindles for RAID6), and monitor the performance of clients during usual workloads. If performance is degraded, increase the thread count and see how that works until performance is degraded again or you reach satisfactory performance.</para>
 151       <informaltable frame="none">
 152         <tgroup cols="1">
 153           <colspec colname="c1" colwidth="100*"/>
 154           <tbody>
 155             <row>
 156               <entry><para><emphasis role="bold">Note -</emphasis><anchor xml:id="dbdoclet.50438272_pgfId-1295670" xreflabel=""/>If there are too many threads, the latency for individual I/O requests can become very high and should be avoided. Set the desired maximum thread count permanently using the method described above.</para></entry>
 157             </row>
 158           </tbody>
 159         </tgroup>
 160       </informaltable>
 161       <section remap="h3">
 162         <title><anchor xml:id="dbdoclet.50438272_pgfId-1295614" xreflabel=""/>25.1.1 <anchor xml:id="dbdoclet.50438272_60005" xreflabel=""/>Specifying the OSS Service <anchor xml:id="dbdoclet.50438272_marker-1294858" xreflabel=""/>Thread Count</title>
 163         <para><anchor xml:id="dbdoclet.50438272_pgfId-1291118" xreflabel=""/>The oss_num_threads parameter enables the number of OST service threads to be specified at module load time on the OSS nodes:</para>
 164         <screen><anchor xml:id="dbdoclet.50438272_pgfId-1291119" xreflabel=""/>options ost oss_num_threads={N}</screen>
 165         <para><anchor xml:id="dbdoclet.50438272_pgfId-1292633" xreflabel=""/>After startup, the minimum and maximum number of OSS thread counts can be set via the {service}.thread_{min,max,started} tunable. To change the tunable at runtime, run:</para>
 166         <para><anchor xml:id="dbdoclet.50438272_pgfId-1293688" xreflabel=""/>lctl {get,set}_param {service}.thread_{min,max,started}</para>
 167         <para><anchor xml:id="dbdoclet.50438272_pgfId-1293692" xreflabel=""/>For details, see <link xl:href="LustreProc.html#50438271_87260">Setting MDS and OSS Thread Counts</link>.</para>
 168       </section>
 169       <section remap="h3">
 170         <title><anchor xml:id="dbdoclet.50438272_pgfId-1293756" xreflabel=""/>25.1.2 Specifying the MDS Service <anchor xml:id="dbdoclet.50438272_marker-1293755" xreflabel=""/>Thread Count</title>
 171         <para><anchor xml:id="dbdoclet.50438272_pgfId-1293828" xreflabel=""/>The mds_num_threads parameter enables the number of MDS service threads to be specified at module load time on the MDS node:</para>
 172         <screen><anchor xml:id="dbdoclet.50438272_pgfId-1291131" xreflabel=""/>options mds mds_num_threads={N}</screen>
 173         <para><anchor xml:id="dbdoclet.50438272_pgfId-1293699" xreflabel=""/>After startup, the minimum and maximum number of MDS thread counts can be set via the {service}.thread_{min,max,started} tunable. To change the tunable at runtime, run:</para>
 174         <para><anchor xml:id="dbdoclet.50438272_pgfId-1293700" xreflabel=""/>lctl {get,set}_param {service}.thread_{min,max,started}</para>
 175         <para><anchor xml:id="dbdoclet.50438272_pgfId-1293704" xreflabel=""/>For details, see <link xl:href="LustreProc.html#50438271_87260">Setting MDS and OSS Thread Counts</link>.</para>
 176         <para><anchor xml:id="dbdoclet.50438272_pgfId-1294918" xreflabel=""/>At this time, no testing has been done to determine the optimal number of MDS threads. The default value varies, based on server size, up to a maximum of 32. The maximum number of threads (MDS_MAX_THREADS) is 512.</para>
 177         <informaltable frame="none">
 178           <tgroup cols="1">
 179             <colspec colname="c1" colwidth="100*"/>
 180             <tbody>
 181               <row>
 182                 <entry><para><emphasis role="bold">Note -</emphasis><anchor xml:id="dbdoclet.50438272_pgfId-1294919" xreflabel=""/>The OSS and MDS automatically start new service threads dynamically, in response to server load within a factor of 4. The default value is calculated the same way as before. Setting the _mu_threads module parameter disables automatic thread creation behavior.</para></entry>
 183               </row>
 184             </tbody>
 185           </tgroup>
 186         </informaltable>
 187       </section>
 188     </section>
 189     <section remap="h2">
 190       <title>25.2 <anchor xml:id="dbdoclet.50438272_73839" xreflabel=""/>Tuning LNET Parameters</title>
 191       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295625" xreflabel=""/>This section describes LNET tunables. that may be necessary on some systems to improve performance. To test the performance of your Lustre network, see <link xl:href="LNETSelfTest.html#50438223_71556">Chapter 23</link>: <link xl:href="LNETSelfTest.html#50438223_21832">Testing Lustre Network Performance (LNET Self-Test)</link>.</para>
 192       <section remap="h3">
 193         <title><anchor xml:id="dbdoclet.50438272_pgfId-1291141" xreflabel=""/>25.2.1 Transmit and Receive Buffer Size</title>
 194         <para><anchor xml:id="dbdoclet.50438272_pgfId-1291142" xreflabel=""/>The kernel allocates buffers for sending and receiving messages on a network.</para>
 195         <para><anchor xml:id="dbdoclet.50438272_pgfId-1295680" xreflabel=""/>ksocklnd has separate parameters for the transmit and receive buffers.</para>
 196         <screen><anchor xml:id="dbdoclet.50438272_pgfId-1291143" xreflabel=""/>options ksocklnd tx_buffer_size=0 rx_buffer_size=0
 197 </screen>
 198         <para><anchor xml:id="dbdoclet.50438272_pgfId-1291144" xreflabel=""/>If these parameters are left at the default value (0), the system automatically tunes the transmit and receive buffer size. In almost every case, this default produces the best performance. Do not attempt to tune these parameters unless you are a network expert.</para>
 199       </section>
 200       <section remap="h3">
 201         <title><anchor xml:id="dbdoclet.50438272_pgfId-1291145" xreflabel=""/>25.2.2 Hardware Interrupts (enable_irq_affinity)</title>
 202         <para><anchor xml:id="dbdoclet.50438272_pgfId-1295715" xreflabel=""/>The hardware interrupts that are generated by network adapters may be handled by any CPU in the system. In some cases, we would like network traffic to remain local to a single CPU to help keep the processor cache warm and minimize the impact of context switches. This is helpful when an SMP system has more than one network interface and ideal when the number of interfaces equals the number of CPUs. To enable the enable_irq_affinity parameter, enter:</para>
 203         <screen><anchor xml:id="dbdoclet.50438272_pgfId-1295742" xreflabel=""/>options ksocklnd enable_irq_affinity=1
 204 </screen>
 205         <para><anchor xml:id="dbdoclet.50438272_pgfId-1295711" xreflabel=""/>In other cases, if you have an SMP platform with a single fast interface such as 10Gb Ethernet and more than two CPUs, you may see performance improve by turning this parameter off.</para>
 206         <screen><anchor xml:id="dbdoclet.50438272_pgfId-1295736" xreflabel=""/>options ksocklnd enable_irq_affinity=0
 207 </screen>
 208         <para><anchor xml:id="dbdoclet.50438272_pgfId-1295685" xreflabel=""/>By default, this parameter is off. As always, you should test the performance to compare the impact of changing this parameter.</para>
 209       </section>
 210     </section>
 211     <section remap="h2">
 212       <title>25.3 <anchor xml:id="dbdoclet.50438272_25884" xreflabel=""/>Lockless <anchor xml:id="dbdoclet.50438272_marker-1291703" xreflabel=""/>I/O Tunables</title>
 213       <para><anchor xml:id="dbdoclet.50438272_pgfId-1291569" xreflabel=""/>The lockless I/O tunable feature allows servers to ask clients to do lockless I/O (liblustre-style where the server does the locking) on contended files.</para>
 214       <para><anchor xml:id="dbdoclet.50438272_pgfId-1291570" xreflabel=""/>The lockless I/O patch introduces these tunables:</para>
 215       <itemizedlist><listitem>
 216           <para><anchor xml:id="dbdoclet.50438272_pgfId-1291571" xreflabel=""/> OST-side:</para>
 217         </listitem>
 218 <listitem>
 219           <para> </para>
 220         </listitem>
 221 </itemizedlist>
 222       <screen><anchor xml:id="dbdoclet.50438272_pgfId-1292156" xreflabel=""/>/proc/fs/lustre/ldlm/namespaces/filter-lustre-*
 223 </screen>
 224       <para><anchor xml:id="dbdoclet.50438272_pgfId-1292119" xreflabel=""/>contended_locks - If the number of lock conflicts in the scan of granted and waiting queues at contended_locks is exceeded, the resource is considered to be contended.</para>
 225       <para><anchor xml:id="dbdoclet.50438272_pgfId-1292125" xreflabel=""/>contention_seconds - The resource keeps itself in a contended state as set in the parameter.</para>
 226       <para><anchor xml:id="dbdoclet.50438272_pgfId-1292131" xreflabel=""/>max_nolock_bytes - Server-side locking set only for requests less than the blocks set in the max_nolock_bytes parameter. If this tunable is set to zero (0), it disables server-side locking for read/write requests.</para>
 227       <itemizedlist><listitem>
 228           <para><anchor xml:id="dbdoclet.50438272_pgfId-1291576" xreflabel=""/> Client-side:</para>
 229         </listitem>
 230 <listitem>
 231           <para> </para>
 232         </listitem>
 233 </itemizedlist>
 234       <screen><anchor xml:id="dbdoclet.50438272_pgfId-1291577" xreflabel=""/>/proc/fs/lustre/llite/lustre-*
 235 </screen>
 236       <para><anchor xml:id="dbdoclet.50438272_pgfId-1292113" xreflabel=""/>contention_seconds - llite inode remembers its contended state for the time specified in this parameter.</para>
 237       <itemizedlist><listitem>
 238           <para><anchor xml:id="dbdoclet.50438272_pgfId-1291579" xreflabel=""/> Client-side statistics:</para>
 239         </listitem>
 240 <listitem>
 241           <para> </para>
 242         </listitem>
 243 </itemizedlist>
 244       <para><anchor xml:id="dbdoclet.50438272_pgfId-1291580" xreflabel=""/>The /proc/fs/lustre/llite/lustre-*/stats file has new rows for lockless I/O statistics.</para>
 245       <para><anchor xml:id="dbdoclet.50438272_pgfId-1291566" xreflabel=""/>lockless_read_bytes and lockless_write_bytes - To count the total bytes read or written, the client makes its own decisions based on the request size. The client does not communicate with the server if the request size is smaller than the min_nolock_size, without acquiring locks by the client.</para>
 246     </section>
 247     <section remap="h2">
 248       <title>25.4 <anchor xml:id="dbdoclet.50438272_80545" xreflabel=""/>Improving Lustre <anchor xml:id="dbdoclet.50438272_marker-1295851" xreflabel=""/>Performance When Working with Small Files</title>
 249       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295854" xreflabel=""/>A Lustre environment where an application writes small file chunks from many clients to a single file will result in bad I/O performance. To improve Lustreâ€™s performance with small files:</para>
 250       <itemizedlist><listitem>
 251           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295855" xreflabel=""/> Have the application aggregate writes some amount before submitting them to Lustre. By default, Lustre enforces POSIX coherency semantics, so it results in lock ping-pong between client nodes if they are all writing to the same file at one time.</para>
 252         </listitem>
 253 <listitem>
 254           <para> </para>
 255         </listitem>
 256 <listitem>
 257           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295856" xreflabel=""/> Have the application do 4kB O_DIRECT sized I/O to the file and disable locking on the output file. This avoids partial-page IO submissions and, by disabling locking, you avoid contention between clients.</para>
 258         </listitem>
 259 <listitem>
 260           <para> </para>
 261         </listitem>
 262 <listitem>
 263           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295857" xreflabel=""/> Have the application write contiguous data.</para>
 264         </listitem>
 265 <listitem>
 266           <para> </para>
 267         </listitem>
 268 <listitem>
 269           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295858" xreflabel=""/> Add more disks or use SSD disks for the OSTs. This dramatically improves the IOPS rate. Consider creating larger OSTs rather than many smaller OSTs due to less overhead (journal, connections, etc).</para>
 270         </listitem>
 271 <listitem>
 272           <para> </para>
 273         </listitem>
 274 <listitem>
 275           <para><anchor xml:id="dbdoclet.50438272_pgfId-1295859" xreflabel=""/> Use RAID-1+0 OSTs instead of RAID-5/6. There is RAID parity overhead for writing small chunks of data to disk.</para>
 276         </listitem>
 277 <listitem>
 278           <para> </para>
 279         </listitem>
 280 </itemizedlist>
 281     </section>
 282     <section remap="h2">
 283       <title>25.5 <anchor xml:id="dbdoclet.50438272_45406" xreflabel=""/>Understanding Why Write Performance Is Better Than Read Performance</title>
 284       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295894" xreflabel=""/>Typically, the performance of write operations on a Lustre cluster is better than read operations. When doing writes, all clients are sending write RPCs asynchronously. The RPCs are allocated, and written to disk in the order they arrive. In many cases, this allows the back-end storage to aggregate writes efficiently.</para>
 285       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295895" xreflabel=""/>In the case of read operations, the reads from clients may come in a different order and need a lot of seeking to get read from the disk. This noticeably hampers the read throughput.</para>
 286       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295896" xreflabel=""/>Currently, there is no readahead on the OSTs themselves, though the clients do readahead. If there are lots of clients doing reads it would not be possible to do any readahead in any case because of memory consumption (consider that even a single RPC (1 MB) readahead for 1000 clients would consume 1 GB of RAM).</para>
 287       <para><anchor xml:id="dbdoclet.50438272_pgfId-1295897" xreflabel=""/>For file systems that use socklnd (TCP, Ethernet) as interconnect, there is also additional CPU overhead because the client cannot receive data without copying it from the network buffers. In the write case, the client CAN send data without the additional data copy. This means that the client is more likely to become CPU-bound during reads than writes.</para>
 288       <!--
 289 Begin SiteCatalyst code version: G.5.
 290 -->
 291       <!--
 292 End SiteCatalyst code version: G.5.
 293 -->
 294         <informaltable frame="none">
 295         <tgroup cols="3">
 296           <colspec colname="c1" colwidth="33*"/>
 297           <colspec colname="c2" colwidth="33*"/>
 298           <colspec colname="c3" colwidth="33*"/>
 299
 300
 301
 302           <tbody>
 303             <row>
 304               <entry align="left"><para>Lustre 2.0 Operations Manual</para></entry>
 305               <entry align="right"><para>821-2076-10</para></entry>
 306               <entry align="right" valign="top"><para><link xl:href="index.html"><inlinemediaobject><imageobject role="html">
 307                         <imagedata contentdepth="26" contentwidth="30" fileref="./shared/toc01.gif" scalefit="1"/>
 308                       </imageobject>
 309 <imageobject role="fo">
 310                         <imagedata contentdepth="100%" contentwidth="" depth="" fileref="./shared/toc01.gif" scalefit="1" width="100%"/>
 311                       </imageobject>
 312 </inlinemediaobject></link><link xl:href="BenchmarkingTests.html"><inlinemediaobject><imageobject role="html">
 313                         <imagedata contentdepth="26" contentwidth="30" fileref="./shared/prev01.gif" scalefit="1"/>
 314                       </imageobject>
 315 <imageobject role="fo">
 316                         <imagedata contentdepth="100%" contentwidth="" depth="" fileref="./shared/prev01.gif" scalefit="1" width="100%"/>
 317                       </imageobject>
 318 </inlinemediaobject></link><link xl:href="V_LustreTroubleshooting.html"><inlinemediaobject><imageobject role="html">
 319                         <imagedata contentdepth="26" contentwidth="30" fileref="./shared/next01.gif" scalefit="1"/>
 320                       </imageobject>
 321 <imageobject role="fo">
 322                         <imagedata contentdepth="100%" contentwidth="" depth="" fileref="./shared/next01.gif" scalefit="1" width="100%"/>
 323                       </imageobject>
 324 </inlinemediaobject></link><link xl:href="ix.html"><inlinemediaobject><imageobject role="html">
 325                         <imagedata contentdepth="26" contentwidth="30" fileref="./shared/index01.gif" scalefit="1"/>
 326                       </imageobject>
 327 <imageobject role="fo">
 328                         <imagedata contentdepth="100%" contentwidth="" depth="" fileref="./shared/index01.gif" scalefit="1" width="100%"/>
 329                       </imageobject>
 330 </inlinemediaobject></link></para></entry>
 331             </row>
 332           </tbody>
 333         </tgroup>
 334       </informaltable>
 335       <para><link xl:href=""/></para>
 336       <para><link xl:href="copyright.html">Copyright</link> © 2011, Oracle and/or its affiliates. All rights reserved.</para>
 337     </section>
 338   </section>
 339 </article>