Whamcloud - gitweb
9a7d38236f948b99daafe7fc4ab2393d98db7d4d
[doc/manual.git] / LustreOperations.xml
1 <?xml version='1.0' encoding='UTF-8'?>
2 <!-- This document was created with Syntext Serna Free. --><chapter xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US" xml:id="lustreoperations">
3   <info>
4     <title xml:id="lustreoperations.title">Lustre Operations</title>
5   </info>
6   <para>Once you have the Lustre file system up and running, you can use the procedures in this section to perform these basic Lustre administration tasks:</para>
7   <itemizedlist>
8     <listitem>
9       <para><xref linkend="dbdoclet.50438194_42877"/></para>
10     </listitem>
11     <listitem>
12       <para><xref linkend="dbdoclet.50438194_24122"/></para>
13     </listitem>
14     <listitem>
15       <para><xref linkend="dbdoclet.50438194_84876"/></para>
16     </listitem>
17     <listitem>
18       <para><xref linkend="dbdoclet.50438194_69255"/></para>
19     </listitem>
20     <listitem>
21       <para><xref linkend="dbdoclet.50438194_57420"/></para>
22     </listitem>
23     <listitem>
24       <para><xref linkend="dbdoclet.50438194_54138"/></para>
25     </listitem>
26     <listitem>
27       <para><xref linkend="dbdoclet.50438194_88063"/></para>
28     </listitem>
29     <listitem>
30       <para><xref linkend="dbdoclet.50438194_88980"/></para>
31     </listitem>
32     <listitem>
33       <para><xref linkend="dbdoclet.50438194_41817"/></para>
34     </listitem>
35     <listitem>
36       <para><xref linkend="dbdoclet.50438194_70905"/></para>
37     </listitem>
38     <listitem>
39       <para><xref linkend="dbdoclet.50438194_16954"/></para>
40     </listitem>
41     <listitem>
42       <para><xref linkend="dbdoclet.50438194_69998"/></para>
43     </listitem>
44     <listitem>
45       <para><xref linkend="dbdoclet.50438194_30872"/></para>
46     </listitem>
47   </itemizedlist>
48   <section xml:id="dbdoclet.50438194_42877">
49     <title>13.1 Mounting by Label</title>
50     <para>The file system name is limited to 8 characters. We have encoded the file system and target information in the disk label, so you can mount by label. This allows system administrators to move disks around without worrying about issues such as SCSI disk reordering or getting the <literal>/dev/device</literal> wrong for a shared target. Soon, file system naming will be made as fail-safe as possible. Currently, Linux disk labels are limited to 16 characters. To identify the target within the file system, 8 characters are reserved, leaving 8 characters for the file system name:</para>
51     <para>&lt;fsname&gt;-MDT0000 or &lt;fsname&gt;-OST0a19</para>
52     <para>To mount by label, use this command:</para>
53     <screen>$ mount -t lustre -L &lt;file system label&gt; &lt;mount point&gt;
54 </screen>
55     <para>This is an example of mount-by-label:</para>
56     <screen>$ mount -t lustre -L testfs-MDT0000 /mnt/mdt
57 </screen>
58     <caution>
59       <para>Mount-by-label should NOT be used in a multi-path environment.</para>
60     </caution>
61     <para>Although the file system name is internally limited to 8 characters, you can mount the clients at any mount point, so file system users are not subjected to short names. Here is an example:</para>
62     <screen>mount -t lustre uml1@tcp0:/shortfs /mnt/&lt;long-file_system-name&gt;
63 </screen>
64   </section>
65   <section xml:id="dbdoclet.50438194_24122">
66     <title>13.2 Starting <anchor xml:id="dbdoclet.50438194_marker-1305696" xreflabel=""/>Lustre</title>
67     <para>The startup order of Lustre components depends on whether you have a combined MGS/MDT or these components are separate.</para>
68     <itemizedlist>
69       <listitem>
70         <para> If you have a combined MGS/MDT, the recommended startup order is OSTs, then the MGS/MDT, and then clients.</para>
71       </listitem>
72       <listitem>
73         <para> </para>
74       </listitem>
75       <listitem>
76         <para> If the MGS and MDT are separate, the recommended startup order is: MGS, then OSTs, then the MDT, and then clients.</para>
77       </listitem>
78       <listitem>
79         <para> </para>
80       </listitem>
81     </itemizedlist>
82     <note>
83       <para>If an OST is added to a Lustre file system with a combined MGS/MDT, then the startup order changes slightly; the MGS must be started first because the OST needs to write its configuration data to it. In this scenario, the startup order is MGS/MDT, then OSTs, then the clients.</para>
84     </note>
85   </section>
86   <section xml:id="dbdoclet.50438194_84876">
87     <title>13.3 Mounting a <anchor xml:id="dbdoclet.50438194_marker-1298863" xreflabel=""/>Server</title>
88     <para>Starting a Lustre server is straightforward and only involves the mount command. Lustre servers can be added to <literal>/etc/fstab</literal>:</para>
89     <screen>mount -t lustre
90 </screen>
91     <para>The mount command generates output similar to this:</para>
92     <screen>/dev/sda1 on /mnt/test/mdt type lustre (rw)
93 /dev/sda2 on /mnt/test/ost0 type lustre (rw)
94 192.168.0.21@tcp:/testfs on /mnt/testfs type lustre (rw)
95 </screen>
96     <para>In this example, the MDT, an OST (ost0) and file system (testfs) are mounted.</para>
97     <screen>LABEL=testfs-MDT0000 /mnt/test/mdt lustre defaults,_netdev,noauto 0 0
98 LABEL=testfs-OST0000 /mnt/test/ost0 lustre defaults,_netdev,noauto 0 0
99 </screen>
100     <para>In general, it is wise to specify noauto and let your high-availability (HA) package manage when to mount the device. If you are not using failover, make sure that networking has been started before mounting a Lustre server. RedHat, SuSE, Debian (and perhaps others) use the <literal>_netdev</literal> flag to ensure that these disks are mounted after the network is up.</para>
101     <para>We are mounting by disk label here--the label of a device can be read with <literal>e2label</literal>. The label of a newly-formatted Lustre server ends in <literal>FFFF</literal>, meaning that it has yet to be assigned. The assignment takes place when the server is first started, and the disk label is updated.</para>
102     <caution>
103       <para>Do not do this when the client and OSS are on the same node, as memory pressure between the client and OSS can lead to deadlocks.</para>
104     </caution>
105     <caution>
106       <para>Mount-by-label should NOT be used in a multi-path environment.</para>
107     </caution>
108   </section>
109   <section xml:id="dbdoclet.50438194_69255">
110     <title>13.4 Unmounting a<anchor xml:id="dbdoclet.50438194_marker-1298879" xreflabel=""/> Server</title>
111     <para>To stop a Lustre server, use the <literal>umount &lt;mount point&gt;</literal> command.</para>
112     <para>For example, to stop <literal>ost0</literal> on mount point <literal>/mnt/test</literal>, run:</para>
113     <screen>$ umount /mnt/test
114 </screen>
115     <para>Gracefully stopping a server with the <literal>umount</literal> command preserves the state of the connected clients. The next time the server is started, it waits for clients to reconnect, and then goes through the recovery procedure.</para>
116     <para>If the force (<literal>-f</literal>) flag is used, then the server evicts all clients and stops WITHOUT recovery. Upon restart, the server does not wait for recovery. Any currently connected clients receive I/O errors until they reconnect.</para>
117     <note>
118       <para>If you are using loopback devices, use the <literal>-d</literal> flag. This flag cleans up loop devices and can always be safely specified.</para>
119     </note>
120   </section>
121   <section xml:id="dbdoclet.50438194_57420">
122     <title>13.5 Specifying Fail<anchor xml:id="dbdoclet.50438194_marker-1298926" xreflabel=""/>out/Failover Mode for OSTs</title>
123     <para>Lustre uses two modes, failout and failover, to handle an OST that has become unreachable because it fails, is taken off the network, is unmounted, etc.</para>
124     <itemizedlist>
125       <listitem>
126         <para> In <emphasis>failout</emphasis> mode, Lustre clients immediately receive errors (EIOs) after a timeout, instead of waiting for the OST to recover.</para>
127       </listitem>
128       <listitem>
129         <para> </para>
130       </listitem>
131       <listitem>
132         <para> In <emphasis>failover</emphasis> mode, Lustre clients wait for the OST to recover.</para>
133       </listitem>
134       <listitem>
135         <para> </para>
136       </listitem>
137     </itemizedlist>
138     <para>By default, the Lustre file system uses failover mode for OSTs. To specify failout mode instead, run this command:</para>
139     <screen>$ mkfs.lustre --fsname=&lt;fsname&gt; --ost --mgsnode=&lt;MGS node NID&gt; --param=&quot;failover\
140 .mode=failout&quot; &lt;block device name&gt;
141 </screen>
142     <para>In this example, failout mode is specified for the OSTs on MGS <literal>uml1</literal>, file system <literal>testfs</literal>.</para>
143     <screen>$ mkfs.lustre --fsname=testfs --ost --mgsnode=uml1 --param=&quot;failover.mode=fa\
144 ilout&quot; /dev/sdb 
145 </screen>
146     <caution>
147       <para>Before running this command, unmount all OSTs that will be affected by the change in the failover/failout mode.</para>
148     </caution>
149     <note>
150       <para>After initial file system configuration, use the tunefs.lustre utility to change the failover/failout mode. For example, to set the failout mode, run:</para>
151       <para><screen>$ tunefs.lustre --param failover.mode=failout &lt;OST partition&gt;</screen></para>
152     </note>
153   </section>
154   <section xml:id="dbdoclet.50438194_54138">
155     <title>13.6 Handling <anchor xml:id="dbdoclet.50438194_marker-1307136" xreflabel=""/>Degraded OST RAID Arrays</title>
156     <para>Lustre includes functionality that notifies Lustre if an external RAID array has degraded performance (resulting in reduced overall file system performance), either because a disk has failed and not been replaced, or because a disk was replaced and is undergoing a rebuild. To avoid a global performance slowdown due to a degraded OST, the MDS can avoid the OST for new object allocation if it is notified of the degraded state.</para>
157     <para>A parameter for each OST, called <literal>degraded</literal>, specifies whether the OST is running in degraded mode or not.</para>
158     <para>To mark the OST as degraded, use:</para>
159     <screen>lctl set_param obdfilter.{OST_name}.degraded=1</screen>
160     <para>To mark that the OST is back in normal operation, use:</para>
161     <screen>lctl set_param obdfilter.{OST_name}.degraded=0
162 </screen>
163     <para>To determine if OSTs are currently in degraded mode, use:</para>
164     <screen>lctl get_param obdfilter.*.degraded
165 </screen>
166     <para>If the OST is remounted due to a reboot or other condition, the flag resets to <literal>0</literal>.</para>
167     <para>It is recommended that this be implemented by an automated script that monitors the status of individual RAID devices.</para>
168   </section>
169   <section xml:id="dbdoclet.50438194_88063">
170     <title>13.7 Running Multiple<anchor xml:id="dbdoclet.50438194_marker-1298939" xreflabel=""/> Lustre File Systems</title>
171     <para>There may be situations in which you want to run multiple file systems. This is doable, as long as you follow specific naming conventions.</para>
172     <para>By default, the <literal>mkfs.lustre</literal> command creates a file system named <literal>lustre</literal>. To specify a different file system name (limited to 8 characters), run this command:</para>
173     <para><screen>mkfs.lustre --fsname=&lt;new file system name&gt;</screen></para>
174     <note>
175       <para>The MDT, OSTs and clients in the new file system must share the same name (prepended to the device name). For example, for a new file system named <literal>foo</literal>, the MDT and two OSTs would be named <literal>foo-MDT0000</literal>, <literal>foo-OST0000</literal>, and <literal>foo-OST0001</literal>.</para>
176     </note>
177     <para>To mount a client on the file system, run:</para>
178     <screen>mount -t lustre mgsnode:/&lt;new fsname&gt; &lt;mountpoint&gt;
179 </screen>
180     <para>For example, to mount a client on file system foo at mount point /mnt/lustre1, run:</para>
181     <screen>mount -t lustre mgsnode:/foo /mnt/lustre1
182 </screen>
183     <note>
184       <para>If a client(s) will be mounted on several file systems, add the following line to <literal>/etc/xattr.conf</literal> file to avoid problems when files are moved between the file systems: <literal>lustre.* skip</literal></para>
185     </note>
186     <note>
187       <para>The MGS is universal; there is only one MGS per Lustre installation, not per file system.</para>
188     </note>
189     <note>
190       <para>There is only one file system per MDT. Therefore, specify <literal>--mdt --mgs</literal> on one file system and -<literal>-mdt --mgsnode=&lt;MGS node NID&gt;</literal> on the other file systems.</para>
191     </note>
192     <para>A Lustre installation with two file systems (<literal>foo</literal> and <literal>bar</literal>) could look like this, where the MGS node is <literal>mgsnode@tcp0</literal> and the mount points are <literal>/mnt/lustre1</literal> and <literal>/mnt/lustre2</literal>.</para>
193     <screen>mgsnode# mkfs.lustre --mgs /mnt/lustre1
194 mdtfoonode# mkfs.lustre --fsname=foo --mdt --mgsnode=mgsnode@tcp0 /mnt/lust\
195 re1
196 ossfoonode# mkfs.lustre --fsname=foo --ost --mgsnode=mgsnode@tcp0 /mnt/lust\
197 re1
198 ossfoonode# mkfs.lustre --fsname=foo --ost --mgsnode=mgsnode@tcp0 /mnt/lust\
199 re2
200 mdtbarnode# mkfs.lustre --fsname=bar --mdt --mgsnode=mgsnode@tcp0 /mnt/lust\
201 re1
202 ossbarnode# mkfs.lustre --fsname=bar --ost --mgsnode=mgsnode@tcp0 /mnt/lust\
203 re1
204 ossbarnode# mkfs.lustre --fsname=bar --ost --mgsnode=mgsnode@tcp0 /mnt/lust\
205 re2
206 </screen>
207     <para>To mount a client on file system foo at mount point <literal>/mnt/lustre1</literal>, run:</para>
208     <screen>mount -t lustre mgsnode@tcp0:/foo /mnt/lustre1
209 </screen>
210     <para>To mount a client on file system bar at mount point <literal>/mnt/lustre2</literal>, run:</para>
211     <screen>mount -t lustre mgsnode@tcp0:/bar /mnt/lustre2
212 </screen>
213   </section>
214   <section xml:id="dbdoclet.50438194_88980">
215     <title>13.8 Setting <anchor xml:id="dbdoclet.50438194_marker-1302467" xreflabel=""/>and Retrieving Lustre Parameters</title>
216     <para>Several options are available for setting parameters in Lustre:</para>
217     <itemizedlist>
218       <listitem>
219         <para> When creating a file system, use mkfs.lustre. See <xref linkend="dbdoclet.50438194_17237"/> below.</para>
220       </listitem>
221       <listitem>
222         <para> When a server is stopped, use tunefs.lustre. See <xref linkend="dbdoclet.50438194_55253"/> below.</para>
223       </listitem>
224       <listitem>
225         <para> When the file system is running, use lctl to set or retrieve Lustre parameters. See <xref linkend="dbdoclet.50438194_51490"/> and <xref linkend="dbdoclet.50438194_63247"/> below.</para>
226       </listitem>
227     </itemizedlist>
228     <section xml:id="dbdoclet.50438194_17237">
229       <title>13.8.1 Setting Parameters with <literal>mkfs.lustre</literal></title>
230       <para>When the file system is created, parameters can simply be added as a <literal>--param</literal> option to the <literal>mkfs.lustre</literal> command. For example:</para>
231       <screen>$ mkfs.lustre --mdt --param=&quot;sys.timeout=50&quot; /dev/sda
232 </screen>
233       <para>For more details about creating a file system,see <xref linkend="configuringlustre"/>. For more details about <literal>mkfs.lustre</literal>, see <xref linkend="systemconfigurationutilities"/>.</para>
234     </section>
235     <section xml:id="dbdoclet.50438194_55253">
236       <title>13.8.2 Setting Parameters with <literal>tunefs.lustre</literal></title>
237       <para>If a server (OSS or MDS) is stopped, parameters can be added using the <literal>--param</literal> option to the <literal>tunefs.lustre</literal> command. For example:</para>
238       <screen>$ tunefs.lustre --param=&quot;failover.node=192.168.0.13@tcp0&quot; /dev/sda
239 </screen>
240       <para>With <literal>tunefs.lustre</literal>, parameters are &quot;additive&quot; -- new parameters are specified in addition to old parameters, they do not replace them. To erase all old <literal>tunefs.lustre</literal> parameters and just use newly-specified parameters, run:</para>
241       <screen>$ tunefs.lustre --erase-params --param=&lt;new parameters&gt; </screen>
242       <para>The tunefs.lustre command can be used to set any parameter settable in a /proc/fs/lustre file and that has its own OBD device, so it can be specified as <literal>&lt;obd|fsname&gt;.&lt;obdtype&gt;.&lt;proc_file_name&gt;=&lt;value&gt;</literal>. For example:</para>
243       <screen>$ tunefs.lustre --param mdt.group_upcall=NONE /dev/sda1
244 </screen>
245       <para>For more details about tunefs.lustre, see <link xl:href="SystemConfigurationUtilities.html#50438219_66186">Chapter 36: System Configuration Utilities</link>.</para>
246     </section>
247     <section xml:id="dbdoclet.50438194_51490">
248       <title>13.8.3 Setting Parameters with <literal>lctl</literal></title>
249       <para>When the file system is running, the <literal>lctl</literal> command can be used to set parameters (temporary or permanent) and report current parameter values. Temporary parameters are active as long as the server or client is not shut down. Permanent parameters live through server and client reboots.</para>
250       <note>
251         <para>The lctl list_param command enables users to list all parameters that can be set. See <xref linkend="dbdoclet.50438194_88217"/>.</para>
252       </note>
253       <para>For more details about the <literal>lctl</literal> command, see the examples in the sections below and <xref linkend="systemconfigurationutilities"/>.</para>
254       <section remap="h4">
255         <title>13.8.3.1 Setting Temporary Parameters</title>
256         <para>Use <literal>lctl set_param</literal> to set temporary parameters on the node where it is run. These parameters map to items in <literal>/proc/{fs,sys}/{lnet,lustre}</literal>. The <literal>lctl set_param</literal> command uses this syntax:</para>
257         <screen>lctl set_param [-n] &lt;obdtype&gt;.&lt;obdname&gt;.&lt;proc_file_name&gt;=&lt;value&gt;
258 </screen>
259         <para>For example:</para>
260         <screen># lctl set_param osc.*.max_dirty_mb=1024
261 osc.myth-OST0000-osc.max_dirty_mb=32 
262 osc.myth-OST0001-osc.max_dirty_mb=32 
263 osc.myth-OST0002-osc.max_dirty_mb=32 
264 osc.myth-OST0003-osc.max_dirty_mb=32 
265 osc.myth-OST0004-osc.max_dirty_mb=32
266 </screen>
267       </section>
268       <section remap="h4">
269         <title>13.8.3.2 <anchor xml:id="dbdoclet.50438194_64195" xreflabel=""/>Setting Permanent Parameters</title>
270         <para>Use the <literal>lctl conf_param</literal> command to set permanent parameters. In general, the <literal>lctl conf_param</literal> command can be used to specify any parameter settable in a <literal>/proc/fs/lustre</literal> file, with its own OBD device. The <literal>lctl conf_param</literal> command uses this syntax (same as the <literal>mkfs.lustre</literal> and <literal>tunefs.lustre</literal> commands):</para>
271         <screen>&lt;obd|fsname&gt;.&lt;obdtype&gt;.&lt;proc_file_name&gt;=&lt;value&gt;) 
272 </screen>
273         <para>Here are a few examples of <literal>lctl conf_param</literal> commands:</para>
274         <screen>$ mgs&gt; lctl conf_param testfs-MDT0000.sys.timeout=40
275 $ lctl conf_param testfs-MDT0000.mdt.group_upcall=NONE 
276 $ lctl conf_param testfs.llite.max_read_ahead_mb=16 
277 $ lctl conf_param testfs-MDT0000.lov.stripesize=2M 
278 $ lctl conf_param testfs-OST0000.osc.max_dirty_mb=29.15 
279 $ lctl conf_param testfs-OST0000.ost.client_cache_seconds=15 
280 $ lctl conf_param testfs.sys.timeout=40 
281 </screen>
282         <caution>
283           <para>Parameters specified with the <literal>lctl conf_param</literal> command are set permanently in the file system&apos;s configuration file on the MGS.</para>
284         </caution>
285       </section>
286       <section remap="h4">
287         <title>13.8.3.3 <anchor xml:id="dbdoclet.50438194_88217" xreflabel=""/>Listing Parameters</title>
288         <para>To list Lustre or LNET parameters that are available to set, use the <literal>lctl list_param</literal> command. For example:</para>
289         <screen>lctl list_param [-FR] &lt;obdtype&gt;.&lt;obdname&gt;
290 </screen>
291         <para>The following arguments are available for the <literal>lctl list_param</literal> command.</para>
292         <para><literal>-F</literal> Add &apos;<literal>/</literal>&apos;, &apos;<literal>@</literal>&apos; or &apos;<literal>=</literal>&apos; for directories, symlinks and writeable files, respectively</para>
293         <para><literal>-R</literal> Recursively lists all parameters under the specified path</para>
294         <para>For example:</para>
295         <screen>$ lctl list_param obdfilter.lustre-OST0000 
296 </screen>
297       </section>
298       <section xml:id="dbdoclet.50438194_63247">
299         <title>13.8.3.4 Reporting Current Parameter Values</title>
300         <para>To report current Lustre parameter values, use the <literal>lctl get_param</literal> command with this syntax:</para>
301         <screen>lctl get_param [-n] &lt;obdtype&gt;.&lt;obdname&gt;.&lt;proc_file_name&gt;
302 </screen>
303         <para>This example reports data on RPC service times.</para>
304         <screen>$ lctl get_param -n ost.*.ost_io.timeouts 
305 service : cur 1 worst 30 (at 1257150393, 85d23h58m54s ago) 1 1 1 1 
306 </screen>
307         <para>This example reports the number of inodes available on each OST.</para>
308         <screen># lctl get_param osc.*.filesfree
309 osc.myth-OST0000-osc-ffff88006dd20000.filesfree=217623 
310 osc.myth-OST0001-osc-ffff88006dd20000.filesfree=5075042 
311 osc.myth-OST0002-osc-ffff88006dd20000.filesfree=3762034 
312 osc.myth-OST0003-osc-ffff88006dd20000.filesfree=91052 
313 osc.myth-OST0004-osc-ffff88006dd20000.filesfree=129651<anchor xml:id="dbdoclet.50438194_88030" xreflabel=""/><anchor xml:id="dbdoclet.50438194_54623" xreflabel=""/></screen>
314       </section>
315     </section>
316   </section>
317   <section xml:id="dbdoclet.50438194_41817">
318     <title>13.9 <anchor xml:id="dbdoclet.50438194_42379" xreflabel=""/><anchor xml:id="dbdoclet.50438194_50129" xreflabel=""/>Specifying NIDs and Failover</title>
319     <para>If a node has multiple network interfaces, it may have multiple NIDs. When a node is specified, all of its NIDs must be listed, delimited by commas (<literal>,</literal>) so other nodes can choose the NID that is appropriate for their network interfaces. When failover nodes are specified, they are delimited by a colon (<literal>:</literal>) or by repeating a keyword (<literal>--mgsnode=</literal> or <literal>--failnode=</literal>). To obtain all NIDs from a node (while LNET is running), run:</para>
320     <screen>lctl list_nids
321 </screen>
322     <para>This displays the server&apos;s NIDs (networks configured to work with Lustre).</para>
323     <para>This example has a combined MGS/MDT failover pair on uml1 and uml2, and a OST failover pair on uml3 and uml4. There are corresponding Elan addresses on uml1 and uml2.</para>
324     <screen>uml1&gt; mkfs.lustre --fsname=testfs --mdt --mgs --failnode=uml2,2@elan /dev/sda1
325 uml1&gt; mount -t lustre /dev/sda1 /mnt/test/mdt
326 uml3&gt; mkfs.lustre --fsname=testfs --ost --failnode=uml4 --mgsnode=uml1,1@ela\
327 n --mgsnode=uml2,2@elan /dev/sdb
328 uml3&gt; mount -t lustre /dev/sdb /mnt/test/ost0
329 client&gt; mount -t lustre uml1,1@elan:uml2,2@elan:/testfs /mnt/testfs
330 uml1&gt; umount /mnt/mdt
331 uml2&gt; mount -t lustre /dev/sda1 /mnt/test/mdt
332 uml2&gt; cat /proc/fs/lustre/mds/testfs-MDT0000/recovery_status
333 </screen>
334     <para>Where multiple NIDs are specified, comma-separation (for example, <literal>uml2,2@elan</literal>) means that the two NIDs refer to the same host, and that Lustre needs to choose the &quot;best&quot; one for communication. Colon-separation (for example, <literal>uml1:uml2</literal>) means that the two NIDs refer to two different hosts, and should be treated as failover locations (Lustre tries the first one, and if that fails, it tries the second one.)</para>
335     <note>
336       <para>If you have an MGS or MDT configured for failover, perform these steps:</para>
337       <orderedlist>
338         <listitem>
339           <para>On the OST, list the NIDs of all MGS nodes at mkfs time.</para>
340           <screen>OST# mkfs.lustre --fsname sunfs --ost --mgsnode=10.0.0.1 \
341   --mgsnode=10.0.0.2 /dev/{device}</screen>
342         </listitem>
343         <listitem>
344           <para>On the client, mount the file system.</para>
345           <para><screen>client# mount -t lustre 10.0.0.1:10.0.0.2:/sunfs /cfs/client/</screen></para>
346         </listitem>
347       </orderedlist>
348     </note>
349   </section>
350   <section xml:id="dbdoclet.50438194_70905">
351     <title>13.10 Erasing a File System</title>
352     <para>If you want to erase a file system, run this command on your targets:</para>
353     <screen>$ &quot;mkfs.lustre -reformat&quot;
354 </screen>
355     <para>If you are using a separate MGS and want to keep other file systems defined on that MGS, then set the <literal>writeconf</literal> flag on the MDT for that file system. The <literal>writeconf</literal> flag causes the configuration logs to be erased; they are regenerated the next time the servers start.</para>
356     <para>To set the <literal>writeconf</literal> flag on the MDT:</para>
357     <orderedlist>
358       <listitem>
359         <para><emphasis role="bold">Unmount all clients/servers using this file system, run:</emphasis></para>
360         <screen>$ umount /mnt/lustre
361 </screen>
362       </listitem>
363       <listitem>
364         <para><emphasis role="bold">Erase the file system and, presumably, replace it with another file system, run:</emphasis></para>
365         <screen>$ mkfs.lustre -reformat --fsname spfs --mdt --mgs /dev/sda
366 </screen>
367       </listitem>
368       <listitem>
369         <para><emphasis role="bold">If you have a separate MGS (that you do not want to reformat), then add the &quot;writeconf&quot; flag to <literal>mkfs.lustre</literal> on the MDT, run:</emphasis></para>
370         <screen>$ mkfs.lustre --reformat --writeconf -fsname spfs --mdt \ --mgs /dev/sda
371 </screen>
372       </listitem>
373     </orderedlist>
374     <note>
375       <para>If you have a combined MGS/MDT, reformatting the MDT reformats the MGS as well, causing all configuration information to be lost; you can start building your new file system. Nothing needs to be done with old disks that will not be part of the new file system, just do not mount them.</para>
376     </note>
377   </section>
378   <section xml:id="dbdoclet.50438194_16954">
379     <title>13.11 Reclaiming Reserved Disk Space</title>
380     <para>All current Lustre installations run the ldiskfs file system internally on service nodes. By default, ldiskfs reserves 5% of the disk space for the root user. In order to reclaim this space, run the following command on your OSSs:</para>
381     <screen>tune2fs [-m reserved_blocks_percent] [device]
382 </screen>
383     <para>You do not need to shut down Lustre before running this command or restart it afterwards.</para>
384   </section>
385   <section xml:id="dbdoclet.50438194_69998">
386     <title>13.12 Replacing an Existing OST or MDS</title>
387     <para>To copy the contents of an existing OST to a new OST (or an old MDS to a new MDS), use one of these methods:</para>
388     <itemizedlist>
389       <listitem>
390         <para>Connect the old OST disk and new OST disk to a single machine, mount both, and use rsync to copy all data between the OST file systems.</para>
391       </listitem>
392     </itemizedlist>
393     <para>For example:</para>
394     <screen>mount -t ldiskfs /dev/old /mnt/ost_old
395 mount -t ldiskfs /dev/new /mnt/ost_new
396 rsync -aSv /mnt/ost_old/ /mnt/ost_new
397 # note trailing slash on ost_old/
398 </screen>
399     <itemizedlist>
400       <listitem>
401         <para> If you are unable to connect both sets of disk to the same computer, use <literal>rsync</literal> to copy over the network using <literal>rsh</literal> (or <literal>ssh</literal> with <literal>-e ssh</literal>):</para>
402       </listitem>
403     </itemizedlist>
404     <screen>rsync -aSvz /mnt/ost_old/ new_ost_node:/mnt/ost_new
405 </screen>
406     <itemizedlist>
407       <listitem>
408         <para>  Use the same procedure for the MDS, with one additional step:</para>
409       </listitem>
410     </itemizedlist>
411     <screen>cd /mnt/mds_old; getfattr -R -e base64 -d . &gt; /tmp/mdsea; \&lt;copy all MDS file\
412 s as above&gt;; cd /mnt/mds_new; setfattr \--restore=/tmp/mdsea
413 </screen>
414   </section>
415   <section xml:id="dbdoclet.50438194_30872">
416     <title>13.13 Identifying To Which Lustre File an OST Object Belongs</title>
417     <para>Use this procedure to identify the file containing a given object on a given OST.</para>
418     <orderedlist>
419       <listitem>
420         <para><emphasis role="bold">On the OST (as root), run <literal>debugfs</literal> to display the file identifier (<literal>FID</literal>) of the file associated with the object.</emphasis></para>
421         <para>For example, if the object is <literal>34976</literal> on <literal>/dev/lustre/ost_test2</literal>, the debug command is:</para>
422         <screen># debugfs -c -R &quot;stat /O/0/d$((34976 %32))/34976&quot; /dev/lustre/ost_test2 
423 </screen>
424         <para>The command output is:</para>
425         <screen>debugfs 1.41.5.sun2 (23-Apr-2009)
426 /dev/lustre/ost_test2: catastrophic mode - not reading inode or group bitma\
427 ps 
428 Inode: 352365   Type: regular    Mode:  0666   Flags: 0x80000
429 Generation: 1574463214    Version: 0xea020000:00000000
430 User:   500   Group:   500   Size: 260096
431 File ACL: 0    Directory ACL: 0
432 Links: 1   Blockcount: 512
433 Fragment:  Address: 0    Number: 0    Size: 0
434 ctime: 0x4a216b48:00000000 -- Sat May 30 13:22:16 2009
435 atime: 0x4a216b48:00000000 -- Sat May 30 13:22:16 2009
436 mtime: 0x4a216b48:00000000 -- Sat May 30 13:22:16 2009
437 crtime: 0x4a216b3c:975870dc -- Sat May 30 13:22:04 2009
438 Size of extra inode fields: 24
439 Extended attributes stored in inode body: 
440 fid = &quot;e2 00 11 00 00 00 00 00 25 43 c1 87 00 00 00 00 a0 88 00 00 00 00 00 \
441 00 00 00 00 00 00 00 00 00 &quot; (32)
442 BLOCKS:
443 (0-63):47968-48031
444 TOTAL: 64
445 </screen>
446       </listitem>
447       <listitem>
448         <para><emphasis role="bold">Note the FID&apos;s EA and apply it to the <literal>osd_inode_id</literal> mapping.</emphasis></para>
449         <para>In this example, the FID&apos;s EA is:</para>
450         <screen>e2001100000000002543c18700000000a0880000000000000000000000000000
451 struct osd_inode_id { 
452 __u64 oii_ino; /* inode number */ 
453 __u32 oii_gen; /* inode generation */ 
454 __u32 oii_pad; /* alignment padding */ 
455 };
456 </screen>
457         <para>After swapping, you get an inode number of <literal>0x001100e2</literal> and generation of <literal>0</literal>.</para>
458       </listitem>
459       <listitem>
460         <para><emphasis role="bold">On the MDT (as root), use <literal>debugfs</literal> to find the file associated with the inode.</emphasis></para>
461         <screen># debugfs -c -R &quot;ncheck 0x001100e2&quot; /dev/lustre/mdt_test 
462 </screen>
463         <para>Here is the command output:</para>
464         <screen>debugfs 1.41.5.sun2 (23-Apr-2009)
465 /dev/lustre/mdt_test: catastrophic mode - not reading inode or group bitmap\
466 s
467 Inode      Pathname
468 1114338    /ROOT/brian-laptop-guest/clients/client11/~dmtmp/PWRPNT/ZD16.BMP
469 </screen>
470       </listitem>
471     </orderedlist>
472     <para>The command lists the inode and pathname associated with the object.</para>
473     <note>
474       <para><literal>Debugfs</literal>&apos; &apos;&apos;ncheck&apos;&apos; is a brute-force search that may take a long time to complete.</para>
475     </note>
476     <note>
477       <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>
478     </note>
479   </section>
480 </chapter>