<para>Shoot The Other Node In The HEAD (STONITH), is a set of power management tools provided with the Linux-HA package. STONITH has native support for many power control devices and is extensible. It uses expect scripts to automate control.</para>
<para>PowerMan, available from the Lawrence Livermore National Laboratory (LLNL), is used to control remote power control (RPC) devices from a central location. PowerMan provides native support for several RPC varieties and expect-like configuration simplifies the addition of new devices.</para>
<para>The latest versions of PowerMan are available at:</para>
- <para><ulink xl:href="http://sourceforge.net/projects/powerman">http://sourceforge.net/projects/powerman</ulink></para>
+ <para><link xl:href="http://sourceforge.net/projects/powerman">http://sourceforge.net/projects/powerman</link></para>
<para>For more information about PowerMan, go to:</para>
- <para><ulink xl:href="https://computing.llnl.gov/linux/powerman.html">https://computing.llnl.gov/linux/powerman.html</ulink></para>
+ <para><link xl:href="https://computing.llnl.gov/linux/powerman.html">https://computing.llnl.gov/linux/powerman.html</link></para>
</section>
<section remap="h3">
<title>11.1.2 Power Equipment</title>
<para>Lustre failover also requires the use of RPC devices, which come in different configurations. Lustre server nodes may be equipped with some kind of service processor that allows remote power control. If a Lustre server node is not equipped with a service processor, then a multi-port, Ethernet-addressable RPC may be used as an alternative. For recommended products, refer to the list of supported RPC devices on the PowerMan website.</para>
- <para><ulink xl:href="https://computing.llnl.gov/linux/powerman.html">https://computing.llnl.gov/linux/powerman.html</ulink></para>
+ <para><link xl:href="https://computing.llnl.gov/linux/powerman.html">https://computing.llnl.gov/linux/powerman.html</link></para>
</section>
</section>
<section xml:id="dbdoclet.50438188_92688">
<para>Lustre must be combined with high-availability (HA) software to enable a complete Lustre failover solution. Lustre can be used with several HA packages including:</para>
<itemizedlist>
<listitem>
- <para><emphasis>Red Hat Cluster Manager</emphasis> - For more information about setting up Lustre failover with Red Hat Cluster Manager, see the Lustre wiki topic <ulink xl:href="http://wiki.lustre.org/index.php/Using_Red_Hat_Cluster_Manager_with_Lustre">Using Red Hat Cluster Manager with Lustre</ulink>.</para>
+ <para><emphasis>Red Hat Cluster Manager</emphasis> - For more information about setting up Lustre failover with Red Hat Cluster Manager, see the Lustre wiki topic <link xl:href="http://wiki.lustre.org/index.php/Using_Red_Hat_Cluster_Manager_with_Lustre">Using Red Hat Cluster Manager with Lustre</link>.</para>
</listitem>
<listitem>
- <para><emphasis>Pacemaker</emphasis> - For more information about setting up Lustre failover with Pacemaker, see the Lustre wiki topic <
ulink xl:href="http://wiki.lustre.org/index.php/Using_Pacemaker_with_Lustre">Using Pacemaker with Lustre</ulink>.<anchor xml:id="dbdoclet.50438188_61775" xreflabel=""/></para>
+ <para><emphasis>Pacemaker</emphasis> - For more information about setting up Lustre failover with Pacemaker, see the Lustre wiki topic <
link xl:href="http://wiki.lustre.org/index.php/Using_Pacemaker_with_Lustre">Using Pacemaker with Lustre</link>.<anchor xml:id="dbdoclet.50438188_61775" xreflabel=""/></para>
</listitem>
</itemizedlist>
</section>
</emphasis>, where <emphasis>
<literal><number_of_data_disks></literal>
</emphasis> does <emphasis>not</emphasis> include the RAID parity disks (1 for RAID 5 and 2 for RAID 6):</para>
- <screen><emphasis><stripe_width_blocks></emphasis> = <emphasis><chunk_blocks></emphasis> * <emphasis><number_of_data_disks></emphasis> = 1 MB
-</screen>
+ <screen><emphasis><stripe_width_blocks></emphasis> = <emphasis><chunk_blocks></emphasis> * <emphasis><number_of_data_disks></emphasis> = 1 MB </screen>
<para>If the RAID configuration does not allow <emphasis>
<literal><chunk_blocks></literal>
- </emphasis> to fit evenly into 1 MB, select <literal>
- <emphasis><chunkblocks></emphasis>
- </literal>, such that <literal>
- <emphasis><stripe_width_blocks></emphasis>
- </literal> is close to 1 MB, but not larger.</para>
+ </emphasis> to fit evenly into 1 MB, select <emphasis>
+ <literal><chunkblocks></literal>
+ </emphasis><emphasis>
+ <literal><stripe_width_blocks></literal>
+ </emphasis>, such that is close to 1 MB, but not larger.</para>
<para>The <emphasis>
<literal><stripe_width_blocks></literal>
- </emphasis> value must equal <literal><emphasis><chunk_blocks></emphasis>*<emphasis><number_of_data_disks></emphasis></literal>. Specifying the <emphasis>
+ </emphasis> value must equal <emphasis>
+ <literal><chunk_blocks>*<number_of_data_disks></literal>
+ </emphasis>. Specifying the <emphasis>
<literal><stripe_width_blocks></literal>
</emphasis> parameter is only relevant for RAID 5 or RAID 6, and is not needed for RAID 1 plus 0.</para>
<para>Run <literal>--reformat</literal> on the file system device (<literal>/dev/sdc</literal>), specifying the RAID geometry to the underlying ldiskfs file system, where:</para>
<screen>--mkfsoptions "<emphasis><other options></emphasis> -E stride=<emphasis><chunk_blocks></emphasis>, stripe_width=<emphasis><stripe_width_blocks></emphasis>"
</screen>
- <para><example>A RAID 6 configuration with 6 disks has 4 data and 2 parity disks. The <literal>
- <emphasis><chunk_blocks></emphasis>
- </literal> <= 1024KB/4 = 256KB.</example></para>
+<informalexample><para>A RAID 6 configuration with 6 disks has 4 data and 2 parity disks. The <emphasis>
+ <literal><chunk_blocks></literal>
+</emphasis> <= 1024KB/4 = 256KB.</para></informalexample>
<para>Because the number of data disks is equal to the power of 2, the stripe width is equal to 1 MB.</para>
<screen>--mkfsoptions "<emphasis><other options></emphasis> -E stride=<emphasis><chunk_blocks></emphasis>, stripe_width=<emphasis><stripe_width_blocks></emphasis>"...
</screen>
<listitem>
<para>Create a journal device on the partition. Run:</para>
<screen>[oss#] mke2fs -b 4096 -O journal_dev /dev/sdb <emphasis><journal_size></emphasis></screen>
- <para>The value of <literal>
- <emphasis><journal_size></emphasis>
- </literal> is specified in units of 4096-byte blocks. For example, 262144 for a 1 GB journal size.</para>
+ <para>The value of <emphasis>
+ <literal><journal_size></literal>
+ </emphasis> is specified in units of 4096-byte blocks. For example, 262144 for a 1 GB journal size.</para>
</listitem>
<listitem>
<para>Create the OST.</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">e2fsprogs</emphasis><anchor xml:id="dbdoclet.50438261_marker-1292893" xreflabel=""/> : Lustre requires a recent version of e2fsprogs that understands extents. Use <literal>e2fsprogs-1.41-90-wc1</literal> or later, available at:</para>
- <para><ulink url="http://build.whamcloud.com/">http://build.whamcloud.com/</ulink></para>
+ <para><link xl:href="http://build.whamcloud.com/">http://build.whamcloud.com/</link></para>
<para>A quilt patchset of all changes to the vanilla e2fsprogs is available in <literal>e2fsprogs-{version}-patches.tgz</literal>.</para>
<note>
<para>The Lustre-patched <literal>e2fsprogs</literal> utility is only required on machines that mount backend (<literal>ldiskfs</literal>) file systems, such as the OSS, MDS and MGS nodes. It does not need to be loaded on clients.</para>
<section remap="h4">
<title>8.1.1.4 (Optional) Debugging Tools and Other Optional Packages</title>
<para>A variety of optional packages are provided on the <emphasis>
- <ulink xl:href="http://downloads.whamcloud.com">Whamcloud download site</ulink>
+ <link xl:href="http://downloads.whamcloud.com">Whamcloud download site</link>
</emphasis>. These include debugging tools, test programs and scripts, Linux kernel and Lustre source code, and other packages.</para>
<para>For more information about debugging tools, see the topic <emphasis>
- <ulink xl:href="http://wiki.lustre.org/index.php/Debugging_Lustre">Debugging Lustre</ulink>
+ <link xl:href="http://wiki.lustre.org/index.php/Debugging_Lustre">Debugging Lustre</link>
</emphasis> on the Lustre wiki.</para>
</section>
</section>
<emphasis role="italic">
<emphasis>(Recommended)</emphasis>
</emphasis>
- </emphasis><emphasis role="bold"> Ensure client clocks are synchronized</emphasis> . Lustre uses client clocks for timestamps. If clocks are out of sync between clients, files will appear with different time stamps when accessed by different clients. Drifting clocks can also cause problems, for example, by making it difficult to debug multi-node issues or correlate logs, which depend on timestamps. We recommend that you use Network Time Protocol (NTP) to keep client and server clocks in sync with each other. For more information about NTP, see: <ulink xl:href="http://www.ntp.org/">http://www.ntp.org</ulink>.</para>
+ </emphasis><emphasis role="bold"> Ensure client clocks are synchronized</emphasis> . Lustre uses client clocks for timestamps. If clocks are out of sync between clients, files will appear with different time stamps when accessed by different clients. Drifting clocks can also cause problems, for example, by making it difficult to debug multi-node issues or correlate logs, which depend on timestamps. We recommend that you use Network Time Protocol (NTP) to keep client and server clocks in sync with each other. For more information about NTP, see: <link xl:href="http://www.ntp.org/">http://www.ntp.org</link>.</para>
</listitem>
</itemizedlist>
</section>
<para><emphasis role="bold">Download the Lustre RPMs.</emphasis></para>
<orderedlist>
<listitem>
- <para><emphasis role="bold">On the <ulink xl:href="http://build.whamcloud.com/">Lustre download site</ulink>, select your platform.</emphasis></para>
+ <para><emphasis role="bold">On the <link xl:href="http://build.whamcloud.com/">Lustre download site</link>, select your platform.</emphasis></para>
<para>The files required to install Lustre (kernels, modules and utilities RPMs) are listed for the selected platform.</para>
</listitem>
<listitem>
<row>
<entry>
<para><emphasis role="bold">Note -</emphasis>The <literal>rpm</literal> command options <literal>--force</literal> or <literal>--nodeps</literal> should not be used to install or update the Lustre-specific <literal>e2fsprogs</literal> package. If errors are reported, file a bug (for instructions see the topic <emphasis>
- <ulink xl:href="http://wiki.lustre.org/index.php/Reporting_Bugs">Reporting Bugs</ulink>
+ <link xl:href="http://wiki.lustre.org/index.php/Reporting_Bugs">Reporting Bugs</link>
</emphasis> on the Lustre wiki).</para>
</entry>
</row>
<screen><mdt node>$ tunefs.lustre --writeconf <device></screen>
</listitem>
<listitem>
+<para>
<emphasis role="bold">
- <para>On each OST, run:</para>
+ On each OST, run:
</emphasis>
- <screen><ost node>$ tunefs.lustre --writeconf <device></screen>
+ <screen><ost node>$ tunefs.lustre --writeconf <device></screen>
+ </para>
</listitem>
</orderedlist>
</listitem>
</para>
<screen>[client]# lfs find --obd <OST UUID> <mount_point> | lfs_migrate -y</screen>
</listitem>
- <listitem> If the OST is no longer available, delete the files on that OST and restore them from backup: <screen>[client]# lfs find --obd <OST UUID> -print0 <mount_point> | \
-tee /tmp/files_to_restore | xargs -0 -n 1 unlink</screen> The list of files that need to be restored from backup is stored in <literal>/tmp/files_to_restore</literal>. Restoring these files is beyond the scope of this document. </listitem>
+ <listitem> <para>If the OST is no longer available, delete the files on that OST and restore them from backup: <screen>[client]# lfs find --obd <OST UUID> -print0 <mount_point> | \
+ tee /tmp/files_to_restore | xargs -0 -n 1 unlink</screen> The list of files that need to be restored from backup is stored in <literal>/tmp/files_to_restore</literal>. Restoring these files is beyond the scope of this document. </para></listitem>
</orderedlist>
</listitem>
- <listitem> <emphasis role="bold">Deactivate the OST.</emphasis> <orderedlist>
- <listitem> To temporarily disable the deactivated OST, enter: <screen>[client]# lctl set_param osc.<fsname>-<OST name>-*.active=0</screen>If there is expected to be a replacement OST in some short time (a few days), the OST can temporarily be deactivated on the clients: <note>
+ <listitem> <para><emphasis role="bold">Deactivate the OST.</emphasis></para> <orderedlist>
+ <listitem> <para>To temporarily disable the deactivated OST, enter: <screen>[client]# lctl set_param osc.<fsname>-<OST name>-*.active=0</screen>If there is expected to be a replacement OST in some short time (a few days), the OST can temporarily be deactivated on the clients: <note>
<para>This setting is only temporary and will be reset if the clients or MDS are rebooted. It needs to be run on all clients.</para>
- </note></listitem>
- <listitem> b. To permanently disable the deactivated OST, enter: <screen>[mgs]# lctl conf_param {OST name}.osc.active=0</screen></listitem>
- </orderedlist>If there is not expected to be a replacement for this OST in the near future, permanently deactivate the OST on all clients and the MDS: <note>
+ </note></para></listitem>
+ <listitem><para>To permanently disable the deactivated OST, enter: <screen>[mgs]# lctl conf_param {OST name}.osc.active=0</screen></para></listitem>
+ </orderedlist><para>If there is not expected to be a replacement for this OST in the near future, permanently deactivate the OST on all clients and the MDS: </para><note>
<para>A removed OST still appears in the file system; do not create a new OST with the same name.</para>
</note></listitem>
</orderedlist>
</section>
- <section remap="h3"><title>14.7.2 Backing Up OST Configuration Files</title>If the OST device is still accessible, then the Lustre configuration files on the OST should be backed up and saved for future use in order to avoid difficulties when a replacement OST is returned to service. These files rarely change, so they can and should be backed up while the OST is functional and accessible. If the deactivated OST is still available to mount (i.e. has not permanently failed or is unmountable due to severe corruption), an effort should be made to preserve these files. <orderedlist>
+ <section remap="h3"><title>14.7.2 Backing Up OST Configuration Files</title><para>If the OST device is still accessible, then the Lustre configuration files on the OST should be backed up and saved for future use in order to avoid difficulties when a replacement OST is returned to service. These files rarely change, so they can and should be backed up while the OST is functional and accessible. If the deactivated OST is still available to mount (i.e. has not permanently failed or is unmountable due to severe corruption), an effort should be made to preserve these files. </para><orderedlist>
<listitem>
+ <para>
<emphasis role="bold">Mount the OST filesystem.</emphasis>
<screen>[oss]# mkdir -p /mnt/ost
[oss]# mount -t ldiskfs {ostdev} /mnt/ost</screen>
+ </para>
</listitem>
<listitem>
+ <para>
<emphasis role="bold">Back up the OST configuration files.</emphasis>
<screen>[oss]# tar cvf {ostname}.tar -C /mnt/ost last_rcvd \
CONFIGS/ O/0/LAST_ID</screen>
+ </para>
</listitem>
<listitem>
+ <para>
<emphasis role="bold">Unmount the OST filesystem.</emphasis>
<screen>[oss]# umount /mnt/ost</screen>
+ </para>
</listitem>
</orderedlist></section>
<section><title>14.7.3 Restoring OST Configuration Files</title>
<para>If the OST configuration files were not backed up, due to the OST file system being completely inaccessible, it is still possible to replace the failed OST with a new one at the same OST index. </para>
<orderedlist>
<listitem>
+ <para>
<emphasis role="bold">Format the OST file system. </emphasis>
<screen>[oss]# mkfs.lustre --ost --index {OST index} {other options} \
{newdev}</screen>
+ </para>
</listitem>
<listitem>
+ <para>
<emphasis role="bold">Mount the OST filesystem. </emphasis>
<screen>[oss]# mkdir /mnt/ost
[oss]# mount -t ldiskfs {newdev} /mnt/ost</screen>
+ </para>
</listitem>
<listitem>
+ <para>
<emphasis role="bold">Restore the OST configuration files, if available. </emphasis>
<screen>[oss]# tar xvf {ostname}.tar -C /mnt/ost</screen>
+ </para>
</listitem>
<listitem>
+ <para>
<emphasis role="bold">Recreate the OST configuration files, if unavailable.</emphasis>
+ </para>
<para>Follow the procedure in <xref linkend='dbdoclet.50438198_69657'/> to recreate the LAST_ID file for this OST index. The <literal>last_rcvd</literal> file will be recreated when the OST is first mounted using the default parameters, which are normally correct for all file systems.
The <literal>CONFIGS/mountdata</literal> file is created by <literal>mkfs.lustre</literal> at format time, but has flags set that request it to register itself with the MGS. It is possible to copy these flags from another working OST (which should be the same):
seek=5 skip=5</screen></para>
</listitem>
<listitem>
+ <para>
<emphasis role="bold">Unmount the OST filesystem.</emphasis>
<screen>[oss]# umount /mnt/ost</screen>
+ </para>
</listitem>
</orderedlist></section>
- <section><title>14.7.4 Returning a Deactivated OST to Service</title> If the OST was permanently deactivated, it needs to be reactivated in the MGS configuration. <screen>[mgs]# lctl conf_param {OST name}.osc.active=1</screen> If the OST was temporarily deactivated, it needs to be reactivated on the MDS and clients. <screen>[mds]# lctl --device <devno> activate
-[client]# lctl set_param osc.<fsname>-<OST name>-*.active=0</screen></section>
+ <section><title>14.7.4 Returning a Deactivated OST to Service</title><para> If the OST was permanently deactivated, it needs to be reactivated in the MGS configuration. <screen>[mgs]# lctl conf_param {OST name}.osc.active=1</screen> If the OST was temporarily deactivated, it needs to be reactivated on the MDS and clients. <screen>[mds]# lctl --device <devno> activate
+ [client]# lctl set_param osc.<fsname>-<OST name>-*.active=0</screen></para></section>
</section>
- <section xml:id="dbdoclet.50438199_77819"><title>14.8 Aborting Recovery</title>You can abort recovery with either the <literal>lctl</literal> utility or by mounting the target with the <literal>abort_recov</literal> option (<literal>mount -o abort_recov</literal>). When starting a target, run: <screen>$ mount -t lustre -L <MDT name> -o abort_recov <mount_point></screen> Note - The recovery process is blocked until all OSTs are available. </section>
- <section xml:id="dbdoclet.50438199_12607"><title>14.9 Determining Which Machine is Serving an OST </title> In the course of administering a Lustre file system, you may need to determine which machine is serving a specific OST. It is not as simple as identifying the machine’s IP address, as IP is only one of several networking protocols that Lustre uses and, as such, LNET does not use IP addresses as node identifiers, but NIDs instead. To identify the NID that is serving a specific OST, run one of the following commands on a client (you do not need to be a root user): <screen>client$ lctl get_param osc.${fsname}-${OSTname}*.ost_conn_uuid</screen> For example: <screen>client$ lctl get_param osc.*-OST0000*.ost_conn_uuid
+ <section xml:id="dbdoclet.50438199_77819"><title>14.8 Aborting Recovery</title><para>You can abort recovery with either the <literal>lctl</literal> utility or by mounting the target with the <literal>abort_recov</literal> option (<literal>mount -o abort_recov</literal>). When starting a target, run: <screen>$ mount -t lustre -L <MDT name> -o abort_recov <mount_point></screen> Note - The recovery process is blocked until all OSTs are available. </para></section>
+ <section xml:id="dbdoclet.50438199_12607"><title>14.9 Determining Which Machine is Serving an OST </title> <para>In the course of administering a Lustre file system, you may need to determine which machine is serving a specific OST. It is not as simple as identifying the machine’s IP address, as IP is only one of several networking protocols that Lustre uses and, as such, LNET does not use IP addresses as node identifiers, but NIDs instead. To identify the NID that is serving a specific OST, run one of the following commands on a client (you do not need to be a root user): <screen>client$ lctl get_param osc.${fsname}-${OSTname}*.ost_conn_uuid</screen> For example: <screen>client$ lctl get_param osc.*-OST0000*.ost_conn_uuid
osc.lustre-OST0000-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp</screen> - OR - <screen>client$ lctl get_param osc.*.ost_conn_uuid
osc.lustre-OST0000-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp
osc.lustre-OST0001-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp
osc.lustre-OST0002-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp
osc.lustre-OST0003-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp
-osc.lustre-OST0004-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp</screen></section>
- <section xml:id="dbdoclet.50438199_62333"><title>14.10 Changing the Address of a Failover Node</title>To change the address of a failover node (e.g, to use node X instead of node Y), run this command on the OSS/OST partition: <screen>tunefs.lustre --erase-params --failnode=<NID> <device> </screen></section>
+osc.lustre-OST0004-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp</screen></para></section>
+ <section xml:id="dbdoclet.50438199_62333"><title>14.10 Changing the Address of a Failover Node</title><para>To change the address of a failover node (e.g, to use node X instead of node Y), run this command on the OSS/OST partition: <screen>tunefs.lustre --erase-params --failnode=<NID> <device> </screen></para></section>
</section>
</chapter>
<section xml:id="dbdoclet.50438273_81684">
<title>12.2 Lustre <anchor xml:id="dbdoclet.50438273_marker-1297386" xreflabel=""/>Monitoring Tool</title>
<para>The Lustre Monitoring Tool (LMT) is a Python-based, distributed system developed and maintained by Lawrence Livermore National Lab (LLNL)). It provides a ''top'' like display of activity on server-side nodes (MDS, OSS and portals routers) on one or more Lustre file systems. It does not provide support for monitoring clients. For more information on LMT, including the setup procedure, see:</para>
- <para><ulink xl:href="http://code.google.com/p/lmt/">http://code.google.com/p/lmt/</ulink></para>
+ <para><link xl:href="http://code.google.com/p/lmt/">http://code.google.com/p/lmt/</link></para>
<para>LMT questions can be directed to:</para>
- <para><ulink xl:href="mailto:lmt-discuss@googlegroups.com">lmt-discuss@googlegroups.com</ulink></para>
+ <para><link xl:href="mailto:lmt-discuss@googlegroups.com">lmt-discuss@googlegroups.com</link></para>
</section>
<section xml:id="dbdoclet.50438273_80593">
<title>12.3 Collect<anchor xml:id="dbdoclet.50438273_marker-1297391" xreflabel=""/>L</title>
<para>CollectL is another tool that can be used to monitor Lustre. You can run CollectL on a Lustre system that has any combination of MDSs, OSTs and clients. The collected data can be written to a file for continuous logging and played back at a later time. It can also be converted to a format suitable for plotting.</para>
<para>For more information about CollectL, see:</para>
- <para><ulink xl:href="http://collectl.sourceforge.net">http://collectl.sourceforge.net</ulink></para>
+ <para><link xl:href="http://collectl.sourceforge.net">http://collectl.sourceforge.net</link></para>
<para>Lustre-specific documentation is also available. See:</para>
- <para><ulink xl:href="http://collectl.sourceforge.net/Tutorial-Lustre.html">http://collectl.sourceforge.net/Tutorial-Lustre.html</ulink></para>
+ <para><link xl:href="http://collectl.sourceforge.net/Tutorial-Lustre.html">http://collectl.sourceforge.net/Tutorial-Lustre.html</link></para>
</section>
<section xml:id="dbdoclet.50438273_44185">
<title>12.4 Other Monitoring Options</title>
<orderedlist>
<listitem>
<para>On the OST, list the NIDs of all MGS nodes at mkfs time.</para>
- <screen><para>OST# mkfs.lustre --fsname sunfs --ost --mgsnode=10.0.0.1</para><para> --mgsnode=10.0.0.2 /dev/{device}</para></screen>
+ <screen>OST# mkfs.lustre --fsname sunfs --ost --mgsnode=10.0.0.1 \
+ --mgsnode=10.0.0.2 /dev/{device}</screen>
</listitem>
<listitem>
<para>On the client, mount the file system.</para>
<para><literal>Debugfs</literal>' ''ncheck'' is a brute-force search that may take a long time to complete.</para>
</note>
<note>
- <para>To find the Lustre file from a disk LBA, follow the steps listed in the document at this URL: <emphasis><ulink>http://smartmontools.sourceforge.net/badblockhowto.html</ulink>. </emphasis> Then, follow the steps above to resolve the Lustre filename.</para>
+ <para>To find the Lustre file from a disk LBA, follow the steps listed in the document at this URL: <emphasis><link xl:href='http://smartmontools.sourceforge.net/badblockhowto.html'>http://smartmontools.sourceforge.net/badblockhowto.html</link>. </emphasis> Then, follow the steps above to resolve the Lustre filename.</para>
</note>
</section>
</chapter>
</screen>
</listitem>
<listitem>
- <emphasis role="bold">
- <para>Append the following lines to the file.</para>
- </emphasis>
+ <para><emphasis role="bold">Append the following lines to the file.</emphasis></para>
<screen>DEVICE=bond0
IPADDR=192.168.10.79 # Use the free IP Address of your network
NETWORK=192.168.10.0
</orderedlist>
</listitem>
<listitem>
- <emphasis role="bold">
- <para>Start/restart the slave interfaces (using your normal network method).</para>
- </emphasis>
+ <para><emphasis role="bold">Start/restart the slave interfaces (using your normal network method).</emphasis></para>
<note>
<para>You must modprobe the bonding module for each bonded interface. If you wish to create bond0 and bond1, two entries in modprobe.conf are required.</para>
</note>
git://git.whamcloud.com / doc / manual.git / commitdiff