[154523.177714] Lustre: Unmounted testfs-client</screen></para>
</listitem>
<listitem><para>Unmount the MDT and MGT</para>
- <para>On the MGS and MDS node(s), use the <literal>umount</literal>
- command:</para>
+ <para>On the MGS and MDS node(s), run the
+ <literal>umount</literal> command:</para>
<para><literal>umount -a -t lustre</literal></para>
<para>The example below shows the unmount of the MDT and MGT for
- the <literal>testfs</literal> filesystem on a combined MGS/MDS:
- </para>
+ the <literal>testfs</literal> filesystem on a combined MGS/MDS:
+ </para>
<para><screen>[root@mds1 ~]# mount |grep lustre
/dev/sda on /mnt/mgt type lustre (ro)
/dev/sdb on /mnt/mdt type lustre (ro)
[155263.566230] Lustre: Failing over testfs-MDT0000
[155263.775355] Lustre: server umount testfs-MDT0000 complete
[155269.843862] Lustre: server umount MGS complete</screen></para>
- <para>For a seperate MGS and MDS, the same command is used, first on
+
<para>For a seperate MGS and MDS, the same command is used, first on
the MDS and then followed by the MGS.</para>
</listitem>
<listitem><para>Unmount all the OSTs</para>
</para>
<para><literal>umount -a -t lustre</literal></para>
<para>The example below shows the unmount of all OSTs for the
- <literal>testfs</literal> filesystem on server
- <literal>OSS1</literal>:
+ <literal>testfs</literal> filesystem on server
+ <literal>OSS1</literal>:
</para>
<para><screen>[root@oss1 ~]# mount |grep lustre
/dev/sda on /mnt/ost0 type lustre (ro)
<title>Setting Temporary Parameters</title>
<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
+ node where it is run. These parameters internally map to corresponding
+ items in the kernel <literal>/proc/{fs,sys}/{lnet,lustre}</literal> and
+ <literal>/sys/{fs,kernel/debug}/lustre</literal> virtual filesystems.
+ However, since the mapping between a particular parameter name and the
+ underlying virtual pathname may change, it is <emphasis>not</emphasis>
+ recommended to access the virtual pathname directly. The
<literal>lctl set_param</literal> command uses this syntax:</para>
<screen>
lctl set_param [-n] [-P]
<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
+ settable parameter with its own OBD device. The
+ <literal>lctl conf_param</literal> command uses the following syntax
+ (the same as the <literal>mkfs.lustre</literal> and
<literal>tunefs.lustre</literal> commands):</para>
<screen>
<replaceable>obdname|fsname</replaceable>.
<replaceable>proc_file_name</replaceable>=
<replaceable>value</replaceable>)
</screen>
+ <note><para>The <literal>lctl conf_param</literal> and
+ <literal>lctl set_param</literal> syntax is <emphasis>not</emphasis>
+ the same.</para></note>
<para>Here are a few examples of
<literal>lctl conf_param</literal> commands:</para>
<screen>
<section xml:id="dbdoclet.setparamp" condition='l25'>
<title>Setting Permanent Parameters with lctl set_param -P</title>
<para>The <literal>lctl set_param -P</literal> command can also
- set parameters permanently. This command must be issued on the MGS.
+ set parameters permanently using the same syntax as
+ <literal>lctl set_param</literal> and <literal>lctl
+ get_param</literal> commands. This command must be issued on the MGS.
The given parameter is set on every host using
- <literal>lctl</literal> upcall. Parameters map to items in
- <literal>/proc/{fs,sys}/{lnet,lustre}</literal>. The
- <literal>lctl set_param</literal> command uses this syntax:</para>
+ <literal>lctl</literal> upcall. The <literal>lctl set_param</literal>
+ command uses the following syntax:</para>
<screen>
lctl set_param -P
<replaceable>obdtype</replaceable>.
lctl set_param -P -d
<replaceable>obdtype</replaceable>.
<replaceable>obdname</replaceable>.
-<replaceable>proc_file_name</replaceable>
+<replaceable>parameter_name</replaceable>
</screen>
<para>For example:</para>
<screen>
# lctl set_param -P -d osc.*.max_dirty_mb
</screen>
+ <note condition='l2c'><para>Starting in Lustre 2.12, there is
+ <literal>lctl get_param</literal> command can provide
+ <emphasis>tab completion</emphasis> when using an interactive shell
+ with <literal>bash-completion</literal> installed. This simplifies
+ the use of <literal>get_param</literal> significantly, since it
+ provides an interactive list of available parameters.
+ </para></note>
</section>
<section xml:id="dbdoclet.50438194_88217">
<title>Listing Parameters</title>
<replaceable>obdname</replaceable>.
<replaceable>proc_file_name</replaceable>
</screen>
+ <note condition='l2c'><para>Starting in Lustre 2.12, there is
+ <literal>lctl get_param</literal> command can provide
+ <emphasis>tab completion</emphasis> when using an interactive shell
+ with <literal>bash-completion</literal> installed. This simplifies
+ the use of <literal>get_param</literal> significantly, since it
+ provides an interactive list of available parameters.
+ </para></note>
<para>This example reports data on RPC service times.</para>
<screen>
oss# lctl get_param -n ost.*.ost_io.timeouts
</screen></para>
<para>The command output is:
<screen>
-debugfs 1.42.3.wc3 (15-Aug-2012)
+debugfs 1.45.6.wc1 (20-Mar-2020)
/dev/lustre/ost_test2: catastrophic mode - not reading inode or group bitmaps
Inode: 352365 Type: regular Mode: 0666 Flags: 0x80000
Generation: 2393149953 Version: 0x0000002a:00005f81
Extended attributes stored in inode body:
fid = "b9 da 24 00 00 00 00 00 6a fa 0d 3f 01 00 00 00 eb 5b 0b 00 00 00 0000
00 00 00 00 00 00 00 00 " (32)
- fid: objid=34976 seq=0 parent=[0x24dab9:0x3f0dfa6a:0x0] stripe=1
+ fid: objid=34976 seq=0 parent=[0x200000400:0x122:0x0] stripe=1
EXTENTS:
(0-64):4620544-4620607
</screen></para>
</listitem>
<listitem>
- <para>For Lustre software release 2.x file systems, the parent FID will
- be of the form [0x200000400:0x122:0x0] and can be resolved directly
- using the
- <literal>lfs fid2path [0x200000404:0x122:0x0]
- /mnt/lustre</literal> command on any Lustre client, and the process is
+ <para>The parent FID will be of the form
+ <literal>[0x200000400:0x122:0x0]</literal> and can be resolved directly
+ using the command <literal>lfs fid2path [0x200000404:0x122:0x0]
+ /mnt/lustre</literal> on any Lustre client, and the process is
complete.</para>
</listitem>
<listitem>
- <para>In this example the parent inode FID is an upgraded 1.x inode
- (due to the first part of the FID being below 0x200000400), the MDT
- inode number is
+ <para>In cases of an upgraded 1.x inode (if the first part of the
+ FID is below 0x200000400), the MDT inode number is
<literal>0x24dab9</literal> and generation
- <literal>0x3f0dfa6a</literal> and the pathname needs to be resolved
+ <literal>0x3f0dfa6a</literal> and the pathname can also be resolved
using
<literal>debugfs</literal>.</para>
</listitem>
</screen>
<para>Here is the command output:</para>
<screen>
-debugfs 1.42.3.wc2 (15-Aug-2012)
+debugfs 1.42.3.wc3 (15-Aug-2012)
/dev/lustre/mdt_test: catastrophic mode - not reading inode or group bitmap\
s
Inode Pathname
git://git.whamcloud.com / doc / manual.git / blobdiff