-<?xml version="1.0" encoding="UTF-8"?>
-<chapter version="5.0" xml:lang="en-US" xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" xml:id='lustremaintenance'>
- <info>
- <title xml:id='lustremaintenance.title'>Lustre Maintenance</title>
- </info>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298785" xreflabel=""/>Once you have the Lustre file system up and running, you can use the procedures in this section to perform these basic Lustre maintenance tasks:</para>
-
- <itemizedlist><listitem>
- <para><xref linkend="dbdoclet.50438199_85142"/>Working with Inactive OSTs</para>
+<?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="lustremaintenance">
+ <title xml:id="lustremaintenance.title">Lustre Maintenance</title>
+ <para>Once you have the Lustre file system up and running, you can use the procedures in this section to perform these basic Lustre maintenance tasks:</para>
+ <itemizedlist>
+ <listitem>
+ <para><xref linkend="lustremaint.inactiveOST"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.findingNodes"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.mountingServerWithoutLustre"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.regenerateConfigLogs"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.changingservernid"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.clear_conf"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.adding_new_mdt"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.adding_new_ost"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.deactivating_mdt_ost"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.rmremotedir"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.inactivemdt"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.remove_ost"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.ydg_pgt_tl"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.restore_ost"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.ucf_qgt_tl"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.abortRecovery"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.determineOST"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.ChangeAddrFailoverNode"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.seperateCombinedMGSMDT"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.setMDTReadonly"/></para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="lustremaint.tunefallocate"/></para>
+ </listitem>
+ </itemizedlist>
+ <section xml:id="lustremaint.inactiveOST">
+ <title>
+ <indexterm><primary>maintenance</primary></indexterm>
+ <indexterm><primary>maintenance</primary><secondary>inactive OSTs</secondary></indexterm>
+ Working with Inactive OSTs</title>
+ <para>To mount a client or an MDT with one or more inactive OSTs, run commands similar to this:</para>
+ <screen>client# mount -o exclude=testfs-OST0000 -t lustre \
+ uml1:/testfs /mnt/testfs
+ client# lctl get_param lov.testfs-clilov-*.target_obd</screen>
+ <para>To activate an inactive OST on a live client or MDT, use the
+ <literal>lctl activate</literal> command on the OSC device. For example:</para>
+ <screen>lctl --device 7 activate</screen>
+ <note>
+ <para>A colon-separated list can also be specified. For example,
+ <literal>exclude=testfs-OST0000:testfs-OST0001</literal>.</para>
+ </note>
+ </section>
+ <section xml:id="lustremaint.findingNodes">
+ <title><indexterm><primary>maintenance</primary><secondary>finding nodes</secondary></indexterm>
+Finding Nodes in the Lustre File System</title>
+ <para>There may be situations in which you need to find all nodes in
+ your Lustre file system or get the names of all OSTs.</para>
+ <para>To get a list of all Lustre nodes, run this command on the MGS:</para>
+ <screen># lctl get_param mgs.MGS.live.*</screen>
+ <note>
+ <para>This command must be run on the MGS.</para>
+ </note>
+ <para>In this example, file system <literal>testfs</literal> has three
+ nodes, <literal>testfs-MDT0000</literal>,
+ <literal>testfs-OST0000</literal>, and
+ <literal>testfs-OST0001</literal>.</para>
+ <screen>mgs:/root# lctl get_param mgs.MGS.live.*
+ fsname: testfs
+ flags: 0x0 gen: 26
+ testfs-MDT0000
+ testfs-OST0000
+ testfs-OST0001 </screen>
+ <para>To get the names of all OSTs, run this command on the MDS:</para>
+ <screen>mds:/root# lctl get_param lov.*-mdtlov.target_obd </screen>
+ <note>
+ <para>This command must be run on the MDS.</para>
+ </note>
+ <para>In this example, there are two OSTs, testfs-OST0000 and
+ testfs-OST0001, which are both active.</para>
+ <screen>mgs:/root# lctl get_param lov.testfs-mdtlov.target_obd
+0: testfs-OST0000_UUID ACTIVE
+1: testfs-OST0001_UUID ACTIVE </screen>
+ </section>
+ <section xml:id="lustremaint.mountingServerWithoutLustre">
+ <title><indexterm><primary>maintenance</primary><secondary>mounting a server</secondary></indexterm>
+Mounting a Server Without Lustre Service</title>
+ <para>If you are using a combined MGS/MDT, but you only want to start the MGS and not the MDT, run this command:</para>
+ <screen>mount -t lustre <replaceable>/dev/mdt_partition</replaceable> -o nosvc <replaceable>/mount_point</replaceable></screen>
+ <para>The <literal><replaceable>mdt_partition</replaceable></literal> variable is the combined MGS/MDT block device.</para>
+ <para>In this example, the combined MGS/MDT is <literal>testfs-MDT0000</literal> and the mount point is <literal>/mnt/test/mdt</literal>.</para>
+ <screen>$ mount -t lustre -L testfs-MDT0000 -o nosvc /mnt/test/mdt</screen>
+ </section>
+ <section xml:id="lustremaint.regenerateConfigLogs">
+ <title><indexterm><primary>maintenance</primary><secondary>regenerating config logs</secondary></indexterm>
+Regenerating Lustre Configuration Logs</title>
+ <para>If the Lustre file system configuration logs are in a state where
+ the file system cannot be started, use the
+ <literal>tunefs.lustre --writeconf</literal> command to regenerate them.
+ After the <literal>writeconf</literal> command is run and the servers
+ restart, the configuration logs are re-generated and stored on the MGS
+ (as with a new file system).</para>
+ <para>You should only use the <literal>writeconf</literal> command if:</para>
+ <itemizedlist>
+ <listitem>
+ <para>The configuration logs are in a state where the file system cannot start</para>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438199_15240"/>Finding Nodes in the Lustre File System</para>
+ <para>A server NID is being changed</para>
</listitem>
+ </itemizedlist>
+ <para>The <literal>writeconf</literal> command is destructive to some
+ configuration items (e.g. OST pools information and tunables set via
+ <literal>conf_param</literal>), and should be used with caution.</para>
+ <caution>
+ <para>The OST pools feature enables a group of OSTs to be named for
+ file striping purposes. If you use OST pools, be aware that running
+ the <literal>writeconf</literal> command erases
+ <emphasis role="bold">all</emphasis> pools information (as well as
+ any other parameters set via <literal>lctl conf_param</literal>).
+ We recommend that the pools definitions (and
+ <literal>conf_param</literal> settings) be executed via a script,
+ so they can be regenerated easily after <literal>writeconf</literal>
+ is performed. However, tunables saved with <literal>lctl set_param
+ -P</literal> are <emphasis>not</emphasis> erased in this case.</para>
+ </caution>
+ <note>
+ <para>If the MGS still holds any configuration logs, it may be
+ possible to dump these logs to save any parameters stored with
+ <literal>lctl conf_param</literal> by dumping the config logs on
+ the MGS and saving the output:</para>
+<screen>
+mgs# lctl --device MGS llog_print <replaceable>fsname</replaceable>-client
+mgs# lctl --device MGS llog_print <replaceable>fsname</replaceable>-MDT0000
+mgs# lctl --device MGS llog_print <replaceable>fsname</replaceable>-OST0000
+</screen>
+ </note>
+ <para>To regenerate Lustre file system configuration logs:</para>
+ <orderedlist>
<listitem>
- <para><xref linkend="dbdoclet.50438199_26070"/>Mounting a Server Without Lustre Service</para>
+ <para>Stop the file system services in the following order before
+ running the <literal>tunefs.lustre --writeconf</literal> command:
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>Unmount the clients.</para>
+ </listitem>
+ <listitem>
+ <para>Unmount the MDT(s).</para>
+ </listitem>
+ <listitem>
+ <para>Unmount the OST(s).</para>
+ </listitem>
+ <listitem>
+ <para>If the MGS is separate from the MDT it can remain mounted
+ during this process.</para>
+ </listitem>
+ </orderedlist>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438199_54623"/>Regenerating Lustre Configuration Logs</para>
+ <para>Make sure the MDT and OST devices are available.</para>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438199_31353"/>Changing a Server NID</para>
+ <para>Run the <literal>tunefs.lustre --writeconf</literal> command
+ on all target devices.</para>
+ <para>Run writeconf on the MDT(s) first, and then the OST(s).</para>
+ <orderedlist>
+ <listitem>
+ <para>On each MDS, for each MDT run:</para>
+ <screen>mds# tunefs.lustre --writeconf <replaceable>/dev/mdt_device</replaceable></screen>
+ </listitem>
+ <listitem>
+ <para> On each OSS, for each OST run:
+ <screen>oss# tunefs.lustre --writeconf <replaceable>/dev/ost_device</replaceable></screen>
+ </para>
+ </listitem>
+ </orderedlist>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438199_22527"/>Adding a New OST to a Lustre File System</para>
+ <para>Restart the file system in the following order:</para>
+ <orderedlist>
+ <listitem>
+ <para>Mount the separate MGT, if it is not already mounted.</para>
+ </listitem>
+ <listitem>
+ <para>Mount the MDT(s) in order, starting with MDT0000.</para>
+ </listitem>
+ <listitem>
+ <para>Mount the OSTs in order, starting with OST0000.</para>
+ </listitem>
+ <listitem>
+ <para>Mount the clients.</para>
+ </listitem>
+ </orderedlist>
</listitem>
+ </orderedlist>
+ <para>After the <literal>tunefs.lustre --writeconf</literal> command is
+ run, the configuration logs are re-generated as servers connect to the
+ MGS.</para>
+ </section>
+ <section xml:id="lustremaint.changingservernid">
+ <title><indexterm><primary>maintenance</primary><secondary>changing a NID</secondary></indexterm>
+Changing a Server NID</title>
+ <para>In order to totally rewrite the Lustre configuration, the
+ <literal>tunefs.lustre --writeconf</literal> command is used to
+ rewrite all of the configuration files.</para>
+ <para>If you need to change only the NID of the MDT or OST, the
+ <literal>replace_nids</literal> command can simplify this process.
+ The <literal>replace_nids</literal> command differs from
+ <literal>tunefs.lustre --writeconf</literal> in that it does not
+ erase the entire configuration log, precluding the need the need to
+ execute the <literal>writeconf</literal> command on all servers and
+ re-specify all permanent parameter settings. However, the
+ <literal>writeconf</literal> command can still be used if desired.
+ </para>
+ <para>Change a server NID in these situations:</para>
+ <itemizedlist>
<listitem>
- <para><xref linkend="dbdoclet.50438199_14978"/>Removing and Restoring OSTs</para>
+ <para>New server hardware is added to the file system, and the MDS or an OSS is being moved to the new machine.</para>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438199_77819"/>Aborting Recovery</para>
+ <para>New network card is installed in the server.</para>
</listitem>
<listitem>
- <para><xref linkend="dbdoclet.50438199_12607"/>Determining Which Machine is Serving an OST</para>
+ <para>You want to reassign IP addresses.</para>
</listitem>
+ </itemizedlist>
+ <para>To change a server NID:</para>
+ <orderedlist>
<listitem>
- <para><xref linkend="dbdoclet.50438199_62333"/>Changing the Address of a Failover Node</para>
+ <para>Update the LNet configuration in the <literal>/etc/modprobe.conf</literal> file so the list of server NIDs is correct. Use <literal>lctl list_nids</literal> to view the list of server NIDS.</para>
+ <para>The <literal>lctl list_nids</literal> command indicates which network(s) are
+ configured to work with the Lustre file system.</para>
</listitem>
<listitem>
- <para> </para>
+ <para>Shut down the file system in this order:</para>
+ <orderedlist>
+ <listitem>
+ <para>Unmount the clients.</para>
+ </listitem>
+ <listitem>
+ <para>Unmount the MDT.</para>
+ </listitem>
+ <listitem>
+ <para>Unmount all OSTs.</para>
+ </listitem>
+ </orderedlist>
</listitem>
- </itemizedlist>
- <section xml:id="dbdoclet.50438199_42877">
- <title>14.1 <anchor xml:id="dbdoclet.50438199_85142" xreflabel=""/>Working with <anchor xml:id="dbdoclet.50438199_marker-1298888" xreflabel=""/>Inactive OSTs</title>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298890" xreflabel=""/>To mount a client or an MDT with one or more inactive OSTs, run commands similar to this:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1298891" xreflabel=""/>client> mount -o exclude=testfs-OST0000 -t lustre uml1:/testfs\ /mnt/testfs
- <anchor xml:id="dbdoclet.50438199_pgfId-1298892" xreflabel=""/>client> cat /proc/fs/lustre/lov/testfs-clilov-*/target_obd
- </screen>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298893" xreflabel=""/>To activate an inactive OST on a live client or MDT, use the lctl activate command on the OSC device. For example:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1298894" xreflabel=""/>lctl --device 7 activate
- </screen>
-
-
- <note>
- <para>
- A colon-separated list can also be specified. For example, exclude=testfs-OST0000:testfs-OST0001.</para>
- </note>
-
- <section xml:id="dbdoclet.50438199_15240">
- <title>14.2 Finding <anchor xml:id="dbdoclet.50438199_marker-1298897" xreflabel=""/>Nodes in the Lustre File System</title>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298899" xreflabel=""/>There may be situations in which you need to find all nodes in your Lustre file system or get the names of all OSTs.</para>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298900" xreflabel=""/>To get a list of all Lustre nodes, run this command on the MGS:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1298901" xreflabel=""/># cat /proc/fs/lustre/mgs/MGS/live/*
- </screen>
- <note>
- <para>
- This command must be rund on the MGS.
- </para>
- </note>
-
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298903" xreflabel=""/>In this example, file system lustre has three nodes, lustre-MDT0000, lustre-OST0000, and lustre-OST0001.</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1298904" xreflabel=""/>cfs21:/tmp# cat /proc/fs/lustre/mgs/MGS/live/*
- <anchor xml:id="dbdoclet.50438199_pgfId-1298905" xreflabel=""/>fsname: lustre
- <anchor xml:id="dbdoclet.50438199_pgfId-1298906" xreflabel=""/>flags: 0x0 gen: 26
- <anchor xml:id="dbdoclet.50438199_pgfId-1298907" xreflabel=""/>lustre-MDT0000
- <anchor xml:id="dbdoclet.50438199_pgfId-1298908" xreflabel=""/>lustre-OST0000
- <anchor xml:id="dbdoclet.50438199_pgfId-1298909" xreflabel=""/>lustre-OST0001
- </screen>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298910" xreflabel=""/>To get the names of all OSTs, run this command on the MDS:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1298911" xreflabel=""/># cat /proc/fs/lustre/lov/<fsname>-mdtlov/target_obd
- </screen>
- <note>
- <para>
- This command must be rund on the MDS.
- </para>
- </note>
-
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298913" xreflabel=""/>In this example, there are two OSTs, lustre-OST0000 and lustre-OST0001, which are both active.</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1298914" xreflabel=""/>cfs21:/tmp# cat /proc/fs/lustre/lov/lustre-mdtlov/target_obd
- <anchor xml:id="dbdoclet.50438199_pgfId-1298915" xreflabel=""/>0: lustre-OST0000_UUID ACTIVE
- <anchor xml:id="dbdoclet.50438199_pgfId-1298916" xreflabel=""/>1: lustre-OST0001_UUID ACTIVE
- </screen>
- </section>
- <section xml:id="dbdoclet.50438199_26070">
- <title>14.3 Mounting a Server Without <anchor xml:id="dbdoclet.50438199_marker-1298918" xreflabel=""/>Lustre Service</title>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298920" xreflabel=""/>If you are using a combined MGS/MDT, but you only want to start the MGS and not the MDT, run this command:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1298921" xreflabel=""/>mount -t lustre <MDT partition> -o nosvc <mount point>
- </screen>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298922" xreflabel=""/>The <MDT partition> variable is the combined MGS/MDT.</para>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1298923" xreflabel=""/>In this example, the combined MGS/MDT is testfs-MDT0000 and the mount point is mnt/test/mdt.</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1298924" xreflabel=""/>$ mount -t lustre -L testfs-MDT0000 -o nosvc /mnt/test/mdt
- </screen>
- </section>
- <section xml:id="dbdoclet.50438199_54623">
- <title>14.4 Regenerating Lustre <anchor xml:id="dbdoclet.50438199_marker-1305736" xreflabel=""/>Configuration Logs</title>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1304951" xreflabel=""/>If the Lustre system’s configuration logs are in a state where the file system cannot be started, use the writeconf command to erase them. After the writeconf command is run and the servers restart, the configuration logs are re-generated and stored on the MGS (as in a new file system).</para>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1304970" xreflabel=""/>You should only use the writeconf command if:</para>
- <itemizedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1304971" xreflabel=""/> The configuration logs are in a state where the file system cannot start</para>
- </listitem>
- <listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1304972" xreflabel=""/> A server NID is being changed</para>
- </listitem>
- </itemizedlist>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1304973" xreflabel=""/>The writeconf command is destructive to some configuration items (i.e., OST pools information and items set via conf_param), and should be used with caution. To avoid problems:</para>
- <itemizedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1304974" xreflabel=""/> Shut down the file system before running the writeconf command</para>
- </listitem>
- <listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1304975" xreflabel=""/> Run the writeconf command on all servers (MDT first, then OSTs)</para>
- </listitem>
- <listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1306391" xreflabel=""/> Start the file system in this order:</para>
- </listitem>
- <listitem>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1306392" xreflabel=""/> MGS (or the combined MGS/MDT)</para>
- </listitem>
- <listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1306393" xreflabel=""/> MDT</para>
- </listitem>
- <listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1306394" xreflabel=""/> OSTs</para>
- </listitem>
- <listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1304977" xreflabel=""/> Lustre clients</para>
- </listitem>
- </orderedlist>
- </listitem>
- </itemizedlist>
-
- <caution>
- <para>
- The OST pools feature enables a group of OSTs to be named for file striping purposes. If you use OST pools, be aware that running the writeconf command erases <emphasis role="bold">all</emphasis> pools information (as well as any other parameters set via lctl conf_param). We recommend that the pools definitions (and conf_param settings) be executed via a script, so they can be reproduced easily after a writeconf is performed.</para>
- </caution>
-
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1303394" xreflabel=""/>To regenerate Lustre's system configuration logs:</para>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305772" xreflabel=""/>Shut down the file system in this order.</para>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305773" xreflabel=""/>Unmount the clients.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305774" xreflabel=""/>Unmount the MDT.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305775" xreflabel=""/>Unmount all OSTs.</para>
- </listitem></orderedlist>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305776" xreflabel=""/>Make sure the the MDT and OST devices are available.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305777" xreflabel=""/>Run the writeconf command on all servers.</para>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305778" xreflabel=""/>Run writeconf on the MDT first, and then the OSTs.</para>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305779" xreflabel=""/>On the MDT, run:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1305780" xreflabel=""/><mdt node>$ tunefs.lustre --writeconf <device>
- </screen>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305781" xreflabel=""/>On each OST, run:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1305782" xreflabel=""/><ost node>$ tunefs.lustre --writeconf <device>
- </screen>
- </listitem></orderedlist>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305783" xreflabel=""/>Restart the file system in this order.</para>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305784" xreflabel=""/>Mount the MGS (or the combined MGS/MDT).</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305785" xreflabel=""/>Mount the MDT.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305787" xreflabel=""/>Mount the OSTs.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305811" xreflabel=""/>Mount the clients.</para>
- </listitem></orderedlist>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305788" xreflabel=""/>After the writeconf command is run, the configuration logs are re-generated as servers restart.</para>
- </listitem></orderedlist>
- </section>
- <section xml:id="dbdoclet.50438199_31353">
- <title>14.5 Changing a <anchor xml:id="dbdoclet.50438199_marker-1305737" xreflabel=""/>Server NID</title>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1303485" xreflabel=""/>If you need to change the NID on the MDT or an OST, run the writeconf command to erase Lustre configuration information (including server NIDs), and then re-generate the system configuration using updated server NIDs.</para>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1303612" xreflabel=""/>Change a server NID in these situations:</para>
- <itemizedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1303524" xreflabel=""/> New server hardware is added to the file system, and the MDS or an OSS is being moved to the new machine</para>
- </listitem>
- <listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1303542" xreflabel=""/> New network card is installed in the server</para>
- </listitem>
- <listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1303548" xreflabel=""/> You want to reassign IP addresses</para>
- </listitem>
- </itemizedlist>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1303474" xreflabel=""/><anchor xml:id="dbdoclet.50438199_DDE_LINK1" xreflabel=""/>To change a server NID:</para>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1303460" xreflabel=""/>Update the LNET configuration in the /etc/modprobe.conf file so the list of server NIDs (lctl list_nids) is correct.</para>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1304468" xreflabel=""/>The lctl list_nids command indicates which network(s) are configured to work with Lustre.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305816" xreflabel=""/>Shut down the file system in this order.</para>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305817" xreflabel=""/>Unmount the clients.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305818" xreflabel=""/>Unmount the MDT.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305819" xreflabel=""/>Unmount all OSTs.</para>
- </listitem></orderedlist>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305820" xreflabel=""/>Run the writeconf command on all servers.</para>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305821" xreflabel=""/>Run writeconf on the MDT first, and then the OSTs.</para>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305822" xreflabel=""/>On the MDT, run:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1305823" xreflabel=""/><mdt node>$ tunefs.lustre --writeconf <device>
- </screen>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305824" xreflabel=""/>On each OST, run:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1305825" xreflabel=""/><ost node>$ tunefs.lustre --writeconf <device>
- </screen>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305826" xreflabel=""/>If the NID on the MGS was changed, communicate the new MGS location to each server. Run:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1305827" xreflabel=""/>tunefs.lustre --erase-param --mgsnode=<new_nid(s)> --writeconf /dev/..
- </screen>
- </listitem></orderedlist>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305828" xreflabel=""/>Restart the file system in this order.</para>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305829" xreflabel=""/>Mount the MGS (or the combined MGS/MDT).</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305830" xreflabel=""/>Mount the MDT.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305831" xreflabel=""/>Mount the OSTs.</para>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305832" xreflabel=""/>Mount the clients.</para>
- </listitem></orderedlist>
- </listitem></orderedlist>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1305833" xreflabel=""/>After the writeconf command is run, the configuration logs are re-generated as servers restart, and server NIDs in the updated list_nids file are used.</para>
- </section>
- <section xml:id="dbdoclet.50438199_22527">
- <title>14.6 Adding a New <anchor xml:id="dbdoclet.50438199_marker-1306353" xreflabel=""/>OST to a Lustre File System</title>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1306355" xreflabel=""/>To add an OST to existing Lustre file system:</para>
- <orderedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1306356" xreflabel=""/> 1. Add a new OST by passing on the following commands, run:</para>
- <screen><anchor xml:id="dbdoclet.50438199_pgfId-1306357" xreflabel=""/>$ mkfs.lustre --fsname=spfs --ost --mgsnode=mds16@tcp0 /dev/sda
- <anchor xml:id="dbdoclet.50438199_pgfId-1306358" xreflabel=""/>$ mkdir -p /mnt/test/ost0
- <anchor xml:id="dbdoclet.50438199_pgfId-1306359" xreflabel=""/>$ mount -t lustre /dev/sda /mnt/test/ost0
- </screen>
- </listitem><listitem>
- <para><anchor xml:id="dbdoclet.50438199_pgfId-1306360" xreflabel=""/> 2. Migrate the data (possibly).</para>
- </listitem></orderedlist>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306361" xreflabel=""/>The file system is quite unbalanced when new empty OSTs are added. New file creations are automatically balanced. If this is a scratch file system or files are pruned at a regular interval, then no further work may be needed.</para>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306362" xreflabel=""/>New files being created will preferentially be placed on the empty OST. As old files are deleted, they will release space on the old OST.</para>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306363" xreflabel=""/>Files existing prior to the expansion can optionally be rebalanced with an in-place copy, which can be done with a simple script. The basic method is to copy existing files to a temporary file, then move the temp file over the old one. This should not be attempted with files which are currently being written to by users or applications. This operation redistributes the stripes over the entire set of OSTs.</para>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306364" xreflabel=""/>For example, to rebalance all files within /mnt/lustre/dir, enter:</para>
-<screen><anchor xml:id="dbdoclet.50438199_pgfId-1306365" xreflabel=""/>lfs_migrate /mnt/lustre/file
-</screen>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306366" xreflabel=""/>To migrate files within the /test filesystem on OST0004 that are larger than 4GB in size, enter:</para>
-<screen><anchor xml:id="dbdoclet.50438199_pgfId-1306367" xreflabel=""/>lfs find /test -obd test-OST0004 -size +4G | lfs_migrate -y
-</screen>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306368" xreflabel=""/>See <xref linkend='userutilities'/> (lfs_migrate) for more details.</para>
-</section>
-<section xml:id="dbdoclet.50438199_14978">
-<title>14.7 Removing and Restoring OSTs</title>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1304098" xreflabel=""/>OSTs can be removed from and restored to a Lustre file system. Currently in Lustre, removing an OST really means that the OST is 'deactivated' in the file system, not permanently removed. A removed OST still appears in the file system; do not create a new OST with the same name.</para>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1304099" xreflabel=""/>You may want to remove (deactivate) an OST and prevent new files from being written to it in several situations:</para>
-<itemizedlist><listitem>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1304100" xreflabel=""/> Hard drive has failed and a RAID resync/rebuild is underway</para>
-</listitem>
-<listitem>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1304101" xreflabel=""/> OST is nearing its space capacity</para>
-</listitem>
-</itemizedlist>
-<section remap="h3">
-<title><anchor xml:id="dbdoclet.50438199_pgfId-1298979" xreflabel=""/>14.7.1 Removing an OST from the File System</title>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306722" xreflabel=""/>OSTs can be removed from a Lustre file system. Currently in Lustre, removing an OST actually means that the OST is 'deactivated' from the file system, not permanently removed. A removed OST still appears in the device listing; you should not normally create a new OST with the same name.</para>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306724" xreflabel=""/>You may want to deactivate an OST and prevent new files from being written to it in several situations:</para>
-<itemizedlist><listitem>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306725" xreflabel=""/> OST is nearing its space capacity</para>
-</listitem>
-<listitem>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306726" xreflabel=""/> Hard drive has failed and a RAID resync/rebuild is underway</para>
-</listitem>
-<listitem>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306727" xreflabel=""/> OST storage has failed permanently</para>
-</listitem>
-</itemizedlist>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1306729" xreflabel=""/>When removing an OST, remember that the MDT does not communicate directly with OSTs. Rather, each OST has a corresponding OSC which communicates with the MDT. It is necessary to determine the device number of the OSC that corresponds to the OST. Then, you use this device number to deactivate the OSC on the MDT.</para>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1298981" xreflabel=""/>To remove an OST from the file system:</para>
-
-<orderedlist><listitem>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1298982" xreflabel=""/>For the OST to be removed, determine the device number of the corresponding OSC on the MDT.</para>
-<orderedlist><listitem>
-<para> List all OSCs on the node, along with their device numbers. Run:</para>
-<screen><anchor xml:id="dbdoclet.50438199_pgfId-1298984" xreflabel=""/>lctldl|grep " osc "
-</screen>
-<para><anchor xml:id="dbdoclet.50438199_pgfId-1298985" xreflabel=""/>This is sample lctldl|grep</para>
-<screen>
-11 UP osc lustre-OST-0000-osc-cac94211 4ea5b30f-6a8e-55a0-7519-2f20318ebdb4 5
-12 UP osc lustre-OST-0001-osc-cac94211 4ea5b30f-6a8e-55a0-7519-2f20318ebdb4 5
-13 IN osc lustre-OST-0000-osc lustre-MDT0000-mdtlov_UUID 5
-14 UP osc lustre-OST-0001-osc lustre-MDT0000-mdtlov_UUID 5
-</screen>
-</listitem><listitem>
-<para>Determine the device number of the OSC that corresponds to the OST to be removed.</para>
-</listitem></orderedlist>
-</listitem><listitem>
-
-<para>Temporarily deactivate the OSC on the MDT. On the MDT, run: </para>
-
-<screen>
-$ mdt> lctl --device >devno< deactivate
-</screen>
-<para>
-For example, based on the command output in Step 1, to deactivate device 13 (the MDT’s OSC for OST-0000), the command would be:
-</para>
-
-<screen>
-$ mdt> lctl --device 13 deactivate
-</screen>
-
-<para>
-This marks the OST as inactive on the MDS, so no new objects are assigned to the OST. This does not prevent use of existing objects for reads or writes.
-</para>
-
-<note><para>Do not deactivate the OST on the clients. Do so causes errors (EIOs), and the copy out to fail. </para></note>
-
-<caution><para>Do not use lctl conf_param to deactivate the OST. It permanently sets a parameter in the file system configuration.</para></caution>
-
-</listitem><listitem>
-<para>
-Discover all files that have objects residing on the deactivated OST.
-</para>
-
-<para>
-Depending on whether the deactivated OST is available or not, the data from that OST may be migrated to other OSTs, or may need to be restored from backup.
-</para>
-
-<orderedlist><listitem>
-<para>
-If the OST is still online and available, find all files with objects on the deactivated OST, and copy them to other OSTs in the file system to:
-</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 /tmp/files_to_restore. Restoring these files is beyond the scope of this document.
-
-</listitem></orderedlist>
-</listitem><listitem>
-Deactivate the OST.
-
-<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><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><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><listitem>
-1. Mount the OST filesystem.
-
-<screen>
-[oss]# mkdir -p /mnt/ost
-[oss]# mount -t ldiskfs {ostdev} /mnt/ost
-</screen>
-
-</listitem><listitem>
-2. Back up the OST configuration files.
-
-<screen>
-[oss]# tar cvf {ostname}.tar -C /mnt/ost last_rcvd \
-CONFIGS/ O/0/LAST_ID
-</screen>
-
-</listitem><listitem>
-3. Unmount the OST filesystem.
-
-<screen>
-[oss]# umount /mnt/ost
-</screen>
-</listitem></orderedlist>
-
-</section>
-<section>
- <title>14.7.3 Restoring OST Configuration Files</title>
-
-If the original OST is still available, it is best to follow the OST backup and restore procedure given in either Backing Up and Restoring an MDS or OST (Device Level), or Making a File-Level Backup of an OST File System and Restoring a File-Level Backup.
-
-To replace an OST that was removed from service due to corruption or hardware failure, the file system needs to be formatted for Lustre, and the Lustre configuration should be restored, if available.
-
-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.
-
-<orderedlist><listitem>
-1. Format the OST file system.
-
-<screen>
-[oss]# mkfs.lustre --ost --index {OST index} {other options} \
-{newdev}
-</screen>
-
-</listitem><listitem>
-2. Mount the OST filesystem.
-
-<screen>
-[oss]# mkdir /mnt/ost
-[oss]# mount -t ldiskfs {newdev} /mnt/ost
-</screen>
-
-</listitem><listitem>
-3. Restore the OST configuration files, if available.
-
-<screen>
-[oss]# tar xvf {ostname}.tar -C /mnt/ost
-</screen>
-
-</listitem><listitem>
-4. Recreate the OST configuration files, if unavailable.
-
-Follow the procedure in Fixing a Bad LAST_ID on an OST to recreate the LAST_ID file for this OST index. The last_rcvd file will be recreated when the OST is first mounted using the default parameters, which are normally correct for all file systems.
-
-The CONFIGS/mountdata file is created by mkfs.lustre 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):
-
-<screen>
-[oss2]# debugfs -c -R "dump CONFIGS/mountdata /tmp/ldd" \
-{other_osdev}
-[oss2]# scp /tmp/ldd oss:/tmp/ldd
-[oss]# dd if=/tmp/ldd of=/mnt/ost/CONFIGS/mountdata bs=4 count=1 \
-seek=5 skip=5
-</screen>
-
-</listitem><listitem>
-5. Unmount the OST filesystem.
-
-<screen>
-[oss]# umount /mnt/ost
-</screen>
-</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>
- <section xml:id="dbdoclet.50438199_77819">
- <title>14.8 Aborting Recovery</title>
-
-You can abort recovery with either the lctl utility or by mounting the target with the abort_recov option (mount -o abort_recov). When starting a target, run:
-
+ <listitem>
+ <para>If the MGS and MDS share a partition, start the MGS only:</para>
+ <screen>mount -t lustre <replaceable>MDT partition</replaceable> -o nosvc <replaceable>mount_point</replaceable></screen>
+ </listitem>
+ <listitem>
+ <para>Run the <literal>replace_nids</literal> command on the MGS:</para>
+ <screen>lctl replace_nids <replaceable>devicename</replaceable> <replaceable>nid1</replaceable>[,nid2,nid3 ...]</screen>
+ <para>where <replaceable>devicename</replaceable> is the Lustre target name, e.g.
+ <literal>testfs-OST0013</literal></para>
+ </listitem>
+ <listitem>
+ <para>If the MGS and MDS share a partition, stop the MGS:</para>
+ <screen>umount <replaceable>mount_point</replaceable></screen>
+ </listitem>
+ </orderedlist>
+ <note><para>The <literal>replace_nids</literal> command also cleans
+ all old, invalidated records out of the configuration log, while
+ preserving all other current settings.</para></note>
+ <note><para>The previous configuration log is backed up on the MGS
+ disk with the suffix <literal>'.bak'</literal>.</para></note>
+ </section>
+ <section xml:id="lustremaint.clear_conf" condition="l2B">
+ <title><indexterm>
+ <primary>maintenance</primary>
+ <secondary>Clearing a config</secondary>
+ </indexterm> Clearing configuration</title>
+ <para>
+ This command runs on MGS node having the MGS device mounted with
+ <literal>-o nosvc.</literal> It cleans up configuration files
+ stored in the CONFIGS/ directory of any records marked SKIP.
+ If the device name is given, then the specific logs for that
+ filesystem (e.g. testfs-MDT0000) are processed. Otherwise, if a
+ filesystem name is given then all configuration files are cleared.
+ The previous configuration log is backed up on the MGS disk with
+ the suffix 'config.timestamp.bak'. Eg: Lustre-MDT0000-1476454535.bak.
+ </para>
+ <para> To clear a configuration:</para>
+ <orderedlist>
+ <listitem>
+ <para>Shut down the file system in this order:</para>
+ <orderedlist>
+ <listitem>
+ <para>Unmount the clients.</para>
+ </listitem>
+ <listitem>
+ <para>Unmount the MDT.</para>
+ </listitem>
+ <listitem>
+ <para>Unmount all OSTs.</para>
+ </listitem>
+ </orderedlist>
+ </listitem>
+ <listitem>
+ <para>
+ If the MGS and MDS share a partition, start the MGS only
+ using "nosvc" option.
+ </para>
+ <screen>mount -t lustre <replaceable>MDT partition</replaceable> -o nosvc <replaceable>mount_point</replaceable></screen>
+ </listitem>
+ <listitem>
+ <para>Run the <literal>clear_conf</literal> command on the MGS:
+ </para>
+ <screen>lctl clear_conf <replaceable>config</replaceable></screen>
+ <para>
+ Example: To clear the configuration for
+ <literal>MDT0000</literal> on a filesystem named
+ <literal>testfs</literal>
+ </para>
+ <screen>mgs# lctl clear_conf testfs-MDT0000</screen>
+ </listitem>
+ </orderedlist>
+ </section>
+ <section xml:id="lustremaint.adding_new_mdt">
+ <title><indexterm>
+ <primary>maintenance</primary>
+ <secondary>adding an MDT</secondary>
+ </indexterm>Adding a New MDT to a Lustre File System</title>
+ <para>Additional MDTs can be added using the DNE feature to serve one
+ or more remote sub-directories within a filesystem, in order to
+ increase the total number of files that can be created in the
+ filesystem, to increase aggregate metadata performance, or to isolate
+ user or application workloads from other users of the filesystem. It
+ is possible to have multiple remote sub-directories reference the
+ same MDT. However, the root directory will always be located on
+ MDT0000. To add a new MDT into the file system:</para>
+ <orderedlist>
+ <listitem>
+ <para>Discover the maximum MDT index. Each MDT must have unique index.</para>
<screen>
-$ mount -t lustre -L <MDT name> -o abort_recov <mount_point>
+client$ lctl dl | grep mdc
+36 UP mdc testfs-MDT0000-mdc-ffff88004edf3c00 4c8be054-144f-9359-b063-8477566eb84e 5
+37 UP mdc testfs-MDT0001-mdc-ffff88004edf3c00 4c8be054-144f-9359-b063-8477566eb84e 5
+38 UP mdc testfs-MDT0002-mdc-ffff88004edf3c00 4c8be054-144f-9359-b063-8477566eb84e 5
+39 UP mdc testfs-MDT0003-mdc-ffff88004edf3c00 4c8be054-144f-9359-b063-8477566eb84e 5
</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):
-
+ </listitem>
+ <listitem>
+ <para>Add the new block device as a new MDT at the next available
+ index. In this example, the next available index is 4.</para>
<screen>
-client$ lctl get_param osc.${fsname}-${OSTname}*.ost_conn_uuid
+mds# mkfs.lustre --reformat --fsname=<replaceable>testfs</replaceable> --mdt --mgsnode=<replaceable>mgsnode</replaceable> --index 4 <replaceable>/dev/mdt4_device</replaceable>
</screen>
-
-For example:
-
+ </listitem>
+ <listitem>
+ <para>Mount the MDTs.</para>
<screen>
-client$ lctl get_param osc.*-OST0000*.ost_conn_uuid
-osc.lustre-OST0000-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp
+mds# mount –t lustre <replaceable>/dev/mdt4_blockdevice</replaceable> /mnt/mdt4
</screen>
-
-- OR -
-
+ </listitem>
+ <listitem>
+ <para>In order to start creating new files and directories on the
+ new MDT(s) they need to be attached into the namespace at one or
+ more subdirectories using the <literal>lfs mkdir</literal> command.
+ All files and directories below those created with
+ <literal>lfs mkdir</literal> will also be created on the same MDT
+ unless otherwise specified.
+ </para>
<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
+client# lfs mkdir -i 3 /mnt/testfs/new_dir_on_mdt3
+client# lfs mkdir -i 4 /mnt/testfs/new_dir_on_mdt4
+client# lfs mkdir -c 4 /mnt/testfs/new_directory_striped_across_4_mdts
</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>
+ </listitem>
+ </orderedlist>
+ </section>
+ <section xml:id="lustremaint.adding_new_ost">
+ <title><indexterm><primary>maintenance</primary><secondary>adding a OST</secondary></indexterm>
+Adding a New OST to a Lustre File System</title>
+ <para>A new OST can be added to existing Lustre file system on either
+ an existing OSS node or on a new OSS node. In order to keep client IO
+ load balanced across OSS nodes for maximum aggregate performance, it is
+ not recommended to configure different numbers of OSTs to each OSS node.
+ </para>
+ <orderedlist>
+ <listitem>
+ <para> Add a new OST by using <literal>mkfs.lustre</literal> as when
+ the filesystem was first formatted, see
+ <xref linkend="dbdoclet.format_ost" /> for details. Each new OST
+ must have a unique index number, use <literal>lctl dl</literal> to
+ see a list of all OSTs. For example, to add a new OST at index 12
+ to the <literal>testfs</literal> filesystem run following commands
+ should be run on the OSS:</para>
+ <screen>oss# mkfs.lustre --fsname=testfs --mgsnode=mds16@tcp0 --ost --index=12 /dev/sda
+oss# mkdir -p /mnt/testfs/ost12
+oss# mount -t lustre /dev/sda /mnt/testfs/ost12</screen>
+ </listitem>
+ <listitem>
+ <para>Balance OST space usage (possibly).</para>
+ <para>The file system can be quite unbalanced when new empty OSTs
+ are added to a relatively full filesystem. New file creations are
+ automatically balanced to favour the new OSTs. If this is a scratch
+ file system or files are pruned at regular intervals, then no further
+ work may be needed to balance the OST space usage as new files being
+ created will preferentially be placed on the less full OST(s). As old
+ files are deleted, they will release space on the old OST(s).</para>
+ <para>Files existing prior to the expansion can optionally be
+ rebalanced using the <literal>lfs_migrate</literal> utility.
+ This redistributes file data over the entire set of OSTs.</para>
+ <para>For example, to rebalance all files within the directory
+ <literal>/mnt/lustre/dir</literal>, enter:</para>
+ <screen>client# lfs_migrate /mnt/lustre/dir</screen>
+ <para>To migrate files within the <literal>/test</literal> file
+ system on <literal>OST0004</literal> that are larger than 4GB in
+ size to other OSTs, enter:</para>
+ <screen>client# lfs find /test --ost test-OST0004 -size +4G | lfs_migrate -y</screen>
+ <para>See <xref linkend="dbdoclet.lfs_migrate"/> for details.</para>
+ </listitem>
+ </orderedlist>
+ </section>
+ <section xml:id="lustremaint.deactivating_mdt_ost">
+ <title><indexterm><primary>maintenance</primary><secondary>restoring an OST</secondary></indexterm>
+ <indexterm><primary>maintenance</primary><secondary>removing an OST</secondary></indexterm>
+Removing and Restoring MDTs and OSTs</title>
+ <para>OSTs and DNE MDTs can be removed from and restored to a Lustre
+ filesystem. Deactivating an OST means that it is temporarily or
+ permanently marked unavailable. Deactivating an OST on the MDS means
+ it will not try to allocate new objects there or perform OST recovery,
+ while deactivating an OST the client means it will not wait for OST
+ recovery if it cannot contact the OST and will instead return an IO
+ error to the application immediately if files on the OST are accessed.
+ An OST may be permanently deactivated from the file system,
+ depending on the situation and commands used.</para>
+ <note><para>A permanently deactivated MDT or OST still appears in the
+ filesystem configuration until the configuration is regenerated with
+ <literal>writeconf</literal> or it is replaced with a new MDT or OST
+ at the same index and permanently reactivated. A deactivated OST
+ will not be listed by <literal>lfs df</literal>.
+ </para></note>
+ <para>You may want to temporarily deactivate an OST on the MDS to
+ prevent new files from being written to it in several situations:</para>
+ <itemizedlist>
+ <listitem>
+ <para>A hard drive has failed and a RAID resync/rebuild is underway,
+ though the OST can also be marked <emphasis>degraded</emphasis> by
+ the RAID system to avoid allocating new files on the slow OST which
+ can reduce performance, see <xref linkend='dbdoclet.degraded_ost' />
+ for more details.
+ </para>
+ </listitem>
+ <listitem>
+ <para>OST is nearing its space capacity, though the MDS will already
+ try to avoid allocating new files on overly-full OSTs if possible,
+ see <xref linkend='dbdoclet.balancing_free_space' /> for details.
+ </para>
+ </listitem>
+ <listitem>
+ <para>MDT/OST storage or MDS/OSS node has failed, and will not
+ be available for some time (or forever), but there is still a
+ desire to continue using the filesystem before it is repaired.</para>
+ </listitem>
+ </itemizedlist>
+ <section xml:id="lustremaint.rmremotedir">
+ <title><indexterm><primary>maintenance</primary><secondary>removing an MDT</secondary></indexterm>Removing an MDT from the File System</title>
+ <para>If the MDT is permanently inaccessible,
+ <literal>lfs rm_entry {directory}</literal> can be used to delete the
+ directory entry for the unavailable MDT. Using <literal>rmdir</literal>
+ would otherwise report an IO error due to the remote MDT being inactive.
+ Please note that if the MDT <emphasis>is</emphasis> available, standard
+ <literal>rm -r</literal> should be used to delete the remote directory.
+ After the remote directory has been removed, the administrator should
+ mark the MDT as permanently inactive with:</para>
+ <screen>lctl conf_param {MDT name}.mdc.active=0</screen>
+ <para>A user can identify which MDT holds a remote sub-directory using
+ the <literal>lfs</literal> utility. For example:</para>
+<screen>client$ lfs getstripe --mdt-index /mnt/lustre/remote_dir1
+1
+client$ mkdir /mnt/lustre/local_dir0
+client$ lfs getstripe --mdt-index /mnt/lustre/local_dir0
+0
</screen>
-
-
-
-
+ <para>The <literal>lfs getstripe --mdt-index</literal> command
+ returns the index of the MDT that is serving the given directory.</para>
+ </section>
+ <section xml:id="lustremaint.inactivemdt">
+ <title>
+ <indexterm><primary>maintenance</primary></indexterm>
+ <indexterm><primary>maintenance</primary><secondary>inactive MDTs</secondary></indexterm>Working with Inactive MDTs</title>
+ <para>Files located on or below an inactive MDT are inaccessible until
+ the MDT is activated again. Clients accessing an inactive MDT will receive
+ an EIO error.</para>
+ </section>
+ <section remap="h3" xml:id="lustremaint.remove_ost">
+ <title><indexterm>
+ <primary>maintenance</primary>
+ <secondary>removing an OST</secondary>
+ </indexterm>Removing an OST from the File System</title>
+ <para>When deactivating an OST, note that the client and MDS each have
+ an OSC device that handles communication with the corresponding OST.
+ To remove an OST from the file system:</para>
+ <orderedlist>
+ <listitem>
+ <para>If the OST is functional, and there are files located on
+ the OST that need to be migrated off of the OST, the file creation
+ for that OST should be temporarily deactivated on the MDS (each MDS
+ if running with multiple MDS nodes in DNE mode).
+ </para>
+ <orderedlist>
+ <listitem>
+ <para condition="l29">With Lustre 2.9 and later, the MDS should be
+ set to only disable file creation on that OST by setting
+ <literal>max_create_count</literal> to zero:
+ <screen>mds# lctl set_param osp.<replaceable>osc_name</replaceable>.max_create_count=0</screen>
+ This ensures that files deleted or migrated off of the OST
+ will have their corresponding OST objects destroyed, and the space
+ will be freed. For example, to disable <literal>OST0000</literal>
+ in the filesystem <literal>testfs</literal>, run:
+ <screen>mds# lctl set_param osp.testfs-OST0000-osc-MDT*.max_create_count=0</screen>
+ on each MDS in the <literal>testfs</literal> filesystem.</para>
+ </listitem>
+ <listitem>
+ <para>With older versions of Lustre, to deactivate the OSC on the
+ MDS node(s) use:
+ <screen>mds# lctl set_param osp.<replaceable>osc_name</replaceable>.active=0</screen>
+ This will prevent the MDS from attempting any communication with
+ that OST, including destroying objects located thereon. This is
+ fine if the OST will be removed permanently, if the OST is not
+ stable in operation, or if it is in a read-only state. Otherwise,
+ the free space and objects on the OST will not decrease when
+ files are deleted, and object destruction will be deferred until
+ the MDS reconnects to the OST.</para>
+ <para>For example, to deactivate <literal>OST0000</literal> in
+ the filesystem <literal>testfs</literal>, run:
+ <screen>mds# lctl set_param osp.testfs-OST0000-osc-MDT*.active=0</screen>
+ Deactivating the OST on the <emphasis>MDS</emphasis> does not
+ prevent use of existing objects for read/write by a client.</para>
+ <note>
+ <para>If migrating files from a working OST, do not deactivate
+ the OST on clients. This causes IO errors when accessing files
+ located there, and migrating files on the OST would fail.</para>
+ </note>
+ <caution>
+ <para>Do not use <literal>lctl conf_param</literal> to
+ deactivate the OST if it is still working, as this immediately
+ and permanently deactivates it in the file system configuration
+ on both the MDS and all clients.</para>
+ </caution>
+ </listitem>
+ </orderedlist>
+ </listitem>
+ <listitem>
+ <para>Discover all files that have objects residing on the
+ deactivated OST. Depending on whether the deactivated OST is
+ available or not, the data from that OST may be migrated to
+ other OSTs, or may need to be restored from backup.</para>
+ <orderedlist>
+ <listitem>
+ <para>If the OST is still online and available, find all
+ files with objects on the deactivated OST, and copy them
+ to other OSTs in the file system to: </para>
+ <screen>client# lfs find --ost <replaceable>ost_name</replaceable> <replaceable>/mount/point</replaceable> | lfs_migrate -y</screen>
+ <para>Note that if multiple OSTs are being deactivated at one
+ time, the <literal>lfs find</literal> command can take multiple
+ <literal>--ost</literal> arguments, and will return files that
+ are located on <emphasis>any</emphasis> of the specified OSTs.
+ </para>
+ </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 --ost <replaceable>ost_uuid</replaceable> -print0 <replaceable>/mount/point</replaceable> |
+ 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>
+ <para>Deactivate the OST.</para>
+ <orderedlist>
+ <listitem>
+ <para>
+ 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 using:
+ <screen>client# lctl set_param osc.<replaceable>fsname</replaceable>-OST<replaceable>number</replaceable>-*.active=0</screen>
+ <note><para>This setting is only temporary and will be reset
+ if the clients are remounted or rebooted. It needs to be run
+ on all clients.</para>
+ </note>
+ </para>
+ </listitem>
+ <listitem>
+ <para>If there is not expected to be a replacement for this OST in
+ the near future, permanently deactivate it on all clients and
+ the MDS by running the following command on the MGS:
+ <screen>mgs# lctl conf_param <replaceable>ost_name</replaceable>.osc.active=0</screen></para>
+ <note><para>A deactivated OST still appears in the file system
+ configuration, though a replacement OST can be created using the
+ <literal>mkfs.lustre --replace</literal> option, see
+ <xref linkend="lustremaint.restore_ost"/>.
+ </para></note>
+ </listitem>
+ </orderedlist>
+ </listitem>
+ </orderedlist>
+ </section>
+ <section remap="h3" xml:id="lustremaint.ydg_pgt_tl">
+ <title><indexterm>
+ <primary>maintenance</primary>
+ <secondary>backing up OST config</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>backup</primary>
+ <secondary>OST config</secondary>
+ </indexterm> 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>Mount the OST file system.
+ <screen>oss# mkdir -p /mnt/ost
+oss# mount -t ldiskfs <replaceable>/dev/ost_device</replaceable> /mnt/ost</screen>
+ </para>
+ </listitem>
+ <listitem>
+ <para>Back up the OST configuration files.
+ <screen>oss# tar cvf <replaceable>ost_name</replaceable>.tar -C /mnt/ost last_rcvd \
+ CONFIGS/ O/0/LAST_ID</screen>
+ </para>
+ </listitem>
+ <listitem>
+ <para> Unmount the OST file system. <screen>oss# umount /mnt/ost</screen>
+ </para>
+ </listitem>
+ </orderedlist>
+ </section>
+ <section xml:id="lustremaint.restore_ost">
+ <title><indexterm>
+ <primary>maintenance</primary>
+ <secondary>restoring OST config</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>backup</primary>
+ <secondary>restoring OST config</secondary>
+ </indexterm> Restoring OST Configuration Files</title>
+ <para>If the original OST is still available, it is best to follow the
+ OST backup and restore procedure given in either
+ <xref linkend="dbdoclet.backup_device"/>, or
+ <xref linkend="backup_fs_level"/> and
+ <xref linkend="backup_fs_level.restore"/>.</para>
+ <para>To replace an OST that was removed from service due to corruption
+ or hardware failure, the replacement OST needs to be formatted using
+ <literal>mkfs.lustre</literal>, and the Lustre file system configuration
+ should be restored, if available. Any objects stored on the OST will
+ be permanently lost, and files using the OST should be deleted and/or
+ restored from backup.</para>
+ <para condition="l25">With Lustre 2.5 and later, it is possible to
+ replace an OST to the same index without restoring the configuration
+ files, using the <literal>--replace</literal> option at format time.
+ <screen>oss# mkfs.lustre --ost --reformat --replace --index=<replaceable>old_ost_index</replaceable> \
+ <replaceable>other_options</replaceable> <replaceable>/dev/new_ost_dev</replaceable></screen>
+ The MDS and OSS will negotiate the <literal>LAST_ID</literal> value
+ for the replacement OST.
+ </para>
+ <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>For older versions, format the OST file system without the
+ <literal>--replace</literal> option and restore the saved
+ configuration:
+ <screen>oss# mkfs.lustre --ost --reformat --index=<replaceable>old_ost_index</replaceable> \
+ <replaceable>other_options</replaceable> <replaceable>/dev/new_ost_dev</replaceable></screen>
+ </para>
+ </listitem>
+ <listitem>
+ <para> Mount the OST file system.
+ <screen>oss# mkdir /mnt/ost
+oss# mount -t ldiskfs <replaceable>/dev/new_ost_dev</replaceable> <replaceable>/mnt/ost</replaceable></screen>
+ </para>
+ </listitem>
+ <listitem>
+ <para>Restore the OST configuration files, if available.
+ <screen>oss# tar xvf <replaceable>ost_name</replaceable>.tar -C /mnt/ost</screen></para>
+ </listitem>
+ <listitem>
+ <para>Recreate the OST configuration files, if unavailable. </para>
+ <para>Follow the procedure in
+ <xref linkend="dbdoclet.repair_ost_lastid"/> 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 the flags from another working OST (which should be the same):
+ <screen>oss1# debugfs -c -R "dump CONFIGS/mountdata /tmp" <replaceable>/dev/other_osdev</replaceable>
+oss1# scp /tmp/mountdata oss0:/tmp/mountdata
+oss0# dd if=/tmp/mountdata of=/mnt/ost/CONFIGS/mountdata bs=4 count=1 seek=5 skip=5 conv=notrunc</screen></para>
+ </listitem>
+ <listitem>
+ <para> Unmount the OST file system.
+ <screen>oss# umount /mnt/ost</screen>
+ </para>
+ </listitem>
+ </orderedlist>
+ </section>
+ <section xml:id="lustremaint.ucf_qgt_tl">
+ <title><indexterm>
+ <primary>maintenance</primary>
+ <secondary>reintroducing an OSTs</secondary>
+ </indexterm>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 <replaceable>ost_name</replaceable>.osc.active=1</screen>
+ If the OST was temporarily deactivated, it needs to be reactivated on
+ the MDS and clients.
+ <screen>mds# lctl set_param osp.<replaceable>fsname</replaceable>-OST<replaceable>number</replaceable>-*.active=1
+client# lctl set_param osc.<replaceable>fsname</replaceable>-OST<replaceable>number</replaceable>-*.active=1</screen></para>
+ </section>
+ </section>
+ <section xml:id="lustremaint.abortRecovery">
+ <title><indexterm><primary>maintenance</primary><secondary>aborting recovery</secondary></indexterm>
+ <indexterm><primary>backup</primary><secondary>aborting recovery</secondary></indexterm>
+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>mds# mount -t lustre -L <replaceable>mdt_name</replaceable> -o abort_recov <replaceable>/mount_point</replaceable></screen></para>
+ <note>
+ <para>The recovery process is blocked until all OSTs are available. </para>
+ </note>
+ </section>
+ <section xml:id="lustremaint.determineOST">
+ <title><indexterm><primary>maintenance</primary><secondary>identifying OST host</secondary></indexterm>
+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 the Lustre software 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.<replaceable>fsname</replaceable>-OST<replaceable>number</replaceable>*.ost_conn_uuid</screen>
+ For example:
+ <screen>client$ lctl get_param osc.*-OST0000*.ost_conn_uuid
+osc.testfs-OST0000-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp</screen>-
+ OR -
+ <screen>client$ lctl get_param osc.*.ost_conn_uuid
+osc.testfs-OST0000-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp
+osc.testfs-OST0001-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp
+osc.testfs-OST0002-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp
+osc.testfs-OST0003-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp
+osc.testfs-OST0004-osc-f1579000.ost_conn_uuid=192.168.20.1@tcp</screen></para>
+ </section>
+ <section xml:id="lustremaint.ChangeAddrFailoverNode">
+ <title><indexterm><primary>maintenance</primary><secondary>changing failover node address</secondary></indexterm>
+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 (depending on which option was used to originally
+ identify the NID):
+ <screen>oss# tunefs.lustre --erase-params --servicenode=<replaceable>NID</replaceable> <replaceable>/dev/ost_device</replaceable></screen>
+ or
+ <screen>oss# tunefs.lustre --erase-params --failnode=<replaceable>NID</replaceable> <replaceable>/dev/ost_device</replaceable></screen>
+ For more information about the <literal>--servicenode</literal> and
+ <literal>--failnode</literal> options, see <xref xmlns:xlink="http://www.w3.org/1999/xlink"
+ linkend="configuringfailover"/>.</para>
+ </section>
+ <section xml:id="lustremaint.seperateCombinedMGSMDT">
+ <title><indexterm><primary>maintenance</primary><secondary>separate a
+ combined MGS/MDT</secondary></indexterm>
+ Separate a combined MGS/MDT</title>
+ <para>These instructions assume the MGS node will be the same as the MDS
+ node. For instructions on how to move MGS to a different node, see
+ <xref linkend="lustremaint.changingservernid"/>.</para>
+ <para>These instructions are for doing the split without shutting down
+ other servers and clients.</para>
+ <orderedlist>
+ <listitem>
+ <para>Stop the MDS.</para>
+ <para>Unmount the MDT</para>
+ <screen>umount -f <replaceable>/dev/mdt_device</replaceable> </screen>
+ </listitem>
+ <listitem>
+ <para>Create the MGS.</para>
+ <screen>mds# mkfs.lustre --mgs --device-size=<replaceable>size</replaceable> <replaceable>/dev/mgs_device</replaceable></screen>
+ </listitem>
+ <listitem>
+ <para>Copy the configuration data from MDT disk to the new MGS disk.</para>
+ <screen>mds# mount -t ldiskfs -o ro <replaceable>/dev/mdt_device</replaceable> <replaceable>/mdt_mount_point</replaceable></screen>
+ <screen>mds# mount -t ldiskfs -o rw <replaceable>/dev/mgs_device</replaceable> <replaceable>/mgs_mount_point</replaceable> </screen>
+ <screen>mds# cp -r <replaceable>/mdt_mount_point</replaceable>/CONFIGS/<replaceable>filesystem_name</replaceable>-* <replaceable>/mgs_mount_point</replaceable>/CONFIGS/. </screen>
+ <screen>mds# umount <replaceable>/mgs_mount_point</replaceable></screen>
+ <screen>mds# umount <replaceable>/mdt_mount_point</replaceable></screen>
+ <para>See <xref linkend="lustremaint.regenerateConfigLogs"/> for alternative method.</para>
+ </listitem>
+ <listitem>
+ <para>Start the MGS.</para>
+ <screen>mgs# mount -t lustre <replaceable>/dev/mgs_device</replaceable> <replaceable>/mgs_mount_point</replaceable></screen>
+ <para>Check to make sure it knows about all your file system</para>
+ <screen>mgs:/root# lctl get_param mgs.MGS.filesystems</screen>
+ </listitem>
+ <listitem>
+ <para>Remove the MGS option from the MDT, and set the new MGS nid.</para>
+ <screen>mds# tunefs.lustre --nomgs --mgsnode=<replaceable>new_mgs_nid</replaceable> <replaceable>/dev/mdt-device</replaceable></screen>
+ </listitem>
+ <listitem>
+ <para>Start the MDT.</para>
+ <screen>mds# mount -t lustre <replaceable>/dev/mdt_device /mdt_mount_point</replaceable></screen>
+ <para>Check to make sure the MGS configuration looks right:</para>
+ <screen>mgs# lctl get_param mgs.MGS.live.<replaceable>filesystem_name</replaceable></screen>
+ </listitem>
+ </orderedlist>
</section>
+ <section xml:id="lustremaint.setMDTReadonly" condition="l2D">
+ <title><indexterm><primary>maintenance</primary>
+ <secondary>set an MDT to readonly</secondary></indexterm>
+ Set an MDT to read-only</title>
+ <para>It is sometimes desirable to be able to mark the filesystem
+ read-only directly on the server, rather than remounting the clients and
+ setting the option there. This can be useful if there is a rogue client
+ that is deleting files, or when decommissioning a system to prevent
+ already-mounted clients from modifying it anymore.</para>
+ <para>Set the <literal>mdt.*.readonly</literal> parameter to
+ <literal>1</literal> to immediately set the MDT to read-only. All future
+ MDT access will immediately return a "Read-only file system" error
+ (<literal>EROFS</literal>) until the parameter is set to
+ <literal>0</literal> again.</para>
+ <para>Example of setting the <literal>readonly</literal> parameter to
+ <literal>1</literal>, verifying the current setting, accessing from a
+ client, and setting the parameter back to <literal>0</literal>:</para>
+ <screen>mds# lctl set_param mdt.fs-MDT0000.readonly=1
+mdt.fs-MDT0000.readonly=1
+
+mds# lctl get_param mdt.fs-MDT0000.readonly
+mdt.fs-MDT0000.readonly=1
+
+client$ touch test_file
+touch: cannot touch ‘test_file’: Read-only file system
+
+mds# lctl set_param mdt.fs-MDT0000.readonly=0
+mdt.fs-MDT0000.readonly=0</screen>
</section>
+ <section xml:id="lustremaint.tunefallocate" condition="l2E">
+ <title><indexterm><primary>maintenance</primary>
+ <secondary>Tune fallocate</secondary></indexterm>
+ Tune Fallocate for ldiskfs</title>
+ <para>This section shows how to tune/enable/disable fallocate for
+ ldiskfs OSTs.</para>
+ <para>The default <literal>mode=0</literal> is the standard
+ "allocate unwritten extents" behavior used by ext4. This is by far the
+ fastest for space allocation, but requires the unwritten extents to be
+ split and/or zeroed when they are overwritten.</para>
+ <para> The OST fallocate <literal>mode=1</literal> can also be set to use
+ "zeroed extents", which may be handled by "WRITE SAME", "TRIM zeroes data",
+ or other low-level functionality in the underlying block device.</para>
+ <para><literal>mode=-1</literal> completely disables fallocate.</para>
+ <para>Example: To completely disable fallocate</para>
+ <screen>lctl set_param osd-ldiskfs.*.fallocate_zero_blocks=-1</screen>
+ <para>Example: To enable fallocate to use 'zeroed extents'</para>
+ <screen>lctl set_param osd-ldiskfs.*.fallocate_zero_blocks=1</screen>
+ </section>
</chapter>
+<!--
+ vim:expandtab:shiftwidth=2:tabstop=8:
+ -->
git://git.whamcloud.com / doc / manual.git / blobdiff