<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
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US"
xml:id="lustreproc">
<title xml:id="lustreproc.title">Lustre Parameters</title>
- <para>The <literal>/proc</literal> and <literal>/sys</literal> file systems
- acts as an interface to internal data structures in the kernel. This chapter
- describes parameters and tunables that are useful for optimizing and
- monitoring aspects of a Lustre file system. It includes these sections:</para>
+ <para>There are many parameters for Lustre that can tune client and server
+ performance, change behavior of the system, and report statistics about
+ various subsystems. This chapter describes the various parameters and
+ tunables that are useful for optimizing and monitoring aspects of a Lustre
+ file system. It includes these sections:</para>
<itemizedlist>
<listitem>
<para><xref linkend="dbdoclet.50438271_83523"/></para>
</para>
<para>Typically, metrics are accessed via <literal>lctl get_param</literal>
files and settings are changed by via <literal>lctl set_param</literal>.
- While it is possible to access parameters in <literal>/proc</literal>
+ They allow getting and setting multiple parameters with a single command,
+ through the use of wildcards in one or more part of the parameter name.
+ While each of these parameters maps to files in <literal>/proc</literal>
and <literal>/sys</literal> directly, the location of these parameters may
- change between releases, so it is recommended to always use
+ change between Lustre releases, so it is recommended to always use
<literal>lctl</literal> to access the parameters from userspace scripts.
Some data is server-only, some data is client-only, and some data is
exported from the client to the server and is thus duplicated in both
<para>In the examples in this chapter, <literal>#</literal> indicates
a command is entered as root. Lustre servers are named according to the
convention <literal><replaceable>fsname</replaceable>-<replaceable>MDT|OSTnumber</replaceable></literal>.
- The standard UNIX wildcard designation (*) is used.</para>
+ The standard UNIX wildcard designation (*) is used to represent any
+ part of a single component of the parameter name, excluding
+ "<literal>.</literal>" and "<literal>/</literal>".
+ It is also possible to use brace <literal>{}</literal>expansion
+ to specify a list of parameter names efficiently.</para>
</note>
<para>Some examples are shown below:</para>
<itemizedlist>
<listitem>
- <para> To obtain data from a Lustre client:</para>
- <screen># lctl list_param osc.*
-osc.testfs-OST0000-osc-ffff881071d5cc00
-osc.testfs-OST0001-osc-ffff881071d5cc00
-osc.testfs-OST0002-osc-ffff881071d5cc00
-osc.testfs-OST0003-osc-ffff881071d5cc00
-osc.testfs-OST0004-osc-ffff881071d5cc00
-osc.testfs-OST0005-osc-ffff881071d5cc00
-osc.testfs-OST0006-osc-ffff881071d5cc00
-osc.testfs-OST0007-osc-ffff881071d5cc00
-osc.testfs-OST0008-osc-ffff881071d5cc00</screen>
+ <para> To list available OST targets on a Lustre client:</para>
+ <screen># lctl list_param -F osc.*
+osc.testfs-OST0000-osc-ffff881071d5cc00/
+osc.testfs-OST0001-osc-ffff881071d5cc00/
+osc.testfs-OST0002-osc-ffff881071d5cc00/
+osc.testfs-OST0003-osc-ffff881071d5cc00/
+osc.testfs-OST0004-osc-ffff881071d5cc00/
+osc.testfs-OST0005-osc-ffff881071d5cc00/
+osc.testfs-OST0006-osc-ffff881071d5cc00/
+osc.testfs-OST0007-osc-ffff881071d5cc00/
+osc.testfs-OST0008-osc-ffff881071d5cc00/</screen>
<para>In this example, information about OST connections available
- on a client is displayed (indicated by "osc").</para>
+ on a client is displayed (indicated by "osc"). Each of these
+ connections may have numerous sub-parameters as well.</para>
</listitem>
</itemizedlist>
<itemizedlist>
</itemizedlist>
<itemizedlist>
<listitem>
+ <para> To see a specific subset of parameters, use braces, like:
+<screen># lctl list_param osc.*.{checksum,connect}*
+osc.testfs-OST0000-osc-ffff881071d5cc00.checksum_type
+osc.testfs-OST0000-osc-ffff881071d5cc00.checksums
+osc.testfs-OST0000-osc-ffff881071d5cc00.connect_flags
+</screen></para>
+ </listitem>
+ </itemizedlist>
+ <itemizedlist>
+ <listitem>
<para> To view a specific file, use <literal>lctl get_param</literal>:
<screen># lctl get_param osc.lustre-OST0000*.rpc_stats</screen></para>
</listitem>
version and the Lustre version being used. The <literal>lctl</literal>
command insulates scripts from these changes and is preferred over direct
file access, unless as part of a high-performance monitoring system.
- In the <literal>cat</literal> command:</para>
- <itemizedlist>
- <listitem>
- <para>Replace the dots in the path with slashes.</para>
- </listitem>
- <listitem>
- <para>Prepend the path with the appropriate directory component:
- <screen>/{proc,sys}/{fs,sys}/{lustre,lnet}</screen></para>
- </listitem>
- </itemizedlist>
- <para>For example, an <literal>lctl get_param</literal> command may look like
- this:<screen># lctl get_param osc.*.uuid
-osc.testfs-OST0000-osc-ffff881071d5cc00.uuid=594db456-0685-bd16-f59b-e72ee90e9819
-osc.testfs-OST0001-osc-ffff881071d5cc00.uuid=594db456-0685-bd16-f59b-e72ee90e9819
-...</screen></para>
- <para>The equivalent <literal>cat</literal> command may look like this:
- <screen># cat /proc/fs/lustre/osc/*/uuid
-594db456-0685-bd16-f59b-e72ee90e9819
-594db456-0685-bd16-f59b-e72ee90e9819
-...</screen></para>
- <para>or like this:
- <screen># cat /sys/fs/lustre/osc/*/uuid
-594db456-0685-bd16-f59b-e72ee90e9819
-594db456-0685-bd16-f59b-e72ee90e9819
-...</screen></para>
+ </para>
+ <note condition='l2c'><para>Starting in Lustre 2.12, there is
+ <literal>lctl get_param</literal> and <literal>lctl set_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>The <literal>llstat</literal> utility can be used to monitor some
Lustre file system I/O activity over a specified time period. For more
details, see
<itemizedlist>
<listitem>
<para>To enable automatic LRU sizing, set the
- <literal>lru_size</literal> parameter to 0. In this case, the
- <literal>lru_size</literal> parameter shows the current number of locks
+ <literal>lru_size</literal> parameter to 0. In this case, the
+ <literal>lru_size</literal> parameter shows the current number of locks
being used on the client. Dynamic LRU resizing is enabled by default.
- </para>
+ </para>
</listitem>
<listitem>
<para>To specify a maximum number of locks, set the
- <literal>lru_size</literal> parameter to a value other than zero.
- A good default value for compute nodes is around
- <literal>100 * <replaceable>num_cpus</replaceable></literal>.
+ <literal>lru_size</literal> parameter to a value other than zero.
+ A good default value for compute nodes is around
+ <literal>100 * <replaceable>num_cpus</replaceable></literal>.
It is recommended that you only set <literal>lru_size</literal>
- to be signifivantly larger on a few login nodes where multiple
- users access the file system interactively.</para>
+ to be signifivantly larger on a few login nodes where multiple
+ users access the file system interactively.</para>
</listitem>
</itemizedlist>
<para>To clear the LRU on a single client, and, as a result, flush client
<note>
<para>The <literal>lru_size</literal> parameter can only be set
temporarily using <literal>lctl set_param</literal>, it cannot be set
- permanently.</para>
+ permanently.</para>
</note>
<para>To disable dynamic LRU resizing on the clients, run for example:
</para>
<screen># lctl set_param <replaceable>service</replaceable>.threads_<replaceable>min|max|started=num</replaceable> </screen>
</listitem>
<listitem>
- <para>To permanently set this tunable, run:</para>
- <screen># lctl conf_param <replaceable>obdname|fsname.obdtype</replaceable>.threads_<replaceable>min|max|started</replaceable> </screen>
- <para condition='l25'>For version 2.5 or later, run:
- <screen># lctl set_param -P <replaceable>service</replaceable>.threads_<replaceable>min|max|started</replaceable></screen></para>
+ <para>To permanently set this tunable, run the following command on
+ the MGS:
+ <screen>mgs# lctl set_param -P <replaceable>service</replaceable>.threads_<replaceable>min|max|started</replaceable></screen></para>
+ <para condition='l25'>For Lustre 2.5 or earlier, run:
+ <screen>mgs# lctl conf_param <replaceable>obdname|fsname.obdtype</replaceable>.threads_<replaceable>min|max|started</replaceable></screen>
+ </para>
</listitem>
</itemizedlist>
- <para>The following examples show how to set thread counts and get the number of running threads
- for the service <literal>ost_io</literal> using the tunable
- <literal><replaceable>service</replaceable>.threads_<replaceable>min|max|started</replaceable></literal>.</para>
+ <para>The following examples show how to set thread counts and get the
+ number of running threads for the service <literal>ost_io</literal>
+ using the tunable
+ <literal><replaceable>service</replaceable>.threads_<replaceable>min|max|started</replaceable></literal>.</para>
<itemizedlist>
<listitem>
<para>To get the number of running threads, run:</para>
</itemizedlist>
<section remap="h3">
<title><indexterm><primary>pings</primary><secondary>suppress_pings</secondary></indexterm>"suppress_pings" Kernel Module Parameter</title>
- <para>The new option that controls whether pings are suppressed is implemented as the ptlrpc kernel module parameter "suppress_pings". Setting it to "1" on a server turns on ping suppressing for all targets on that server, while leaving it with the default value "0" gives previous pinging behavior. The parameter is ignored on clients and the MGS. While the parameter is recommended to be set persistently via the modprobe.conf(5) mechanism, it also accept online changes through sysfs. Note that an online change only affects connections established later; existing connections' pinging behaviors stay the same.</para>
+ <para>The new option that controls whether pings are suppressed is
+ implemented as the ptlrpc kernel module parameter "suppress_pings".
+ Setting it to "1" on a server turns on ping suppressing for all
+ targets on that server, while leaving it with the default value "0"
+ gives previous pinging behavior. The parameter is ignored on clients
+ and the MGS. While the parameter is recommended to be set persistently
+ via the modprobe.conf(5) mechanism, it also accept online changes
+ through sysfs. Note that an online change only affects connections
+ established later; existing connections' pinging behaviors stay the same.
+ </para>
</section>
<section remap="h3">
<title><indexterm><primary>pings</primary><secondary>evict_client</secondary></indexterm>Client Death Notification</title>
- <para>The required external client death notification shall write UUIDs of dead clients into targets' "evict_client" procfs entries like</para>
- <screen>
-/proc/fs/lustre/obdfilter/testfs-OST0000/evict_client
-/proc/fs/lustre/obdfilter/testfs-OST0001/evict_client
-/proc/fs/lustre/mdt/testfs-MDT0000/evict_client
- </screen>
- <para>Clients' UUIDs can be obtained from their "uuid" procfs entries like</para>
- <screen>
-/proc/fs/lustre/llite/testfs-ffff8800612bf800/uuid
- </screen>
+ <para>The required external client death notification shall write UUIDs
+ of dead clients into targets' <literal>evict_client</literal> procfs
+ entries in order to remove stale clients from recovery.</para>
+ <para>A client UUID can be obtained from their <literal>uuid</literal>
+ procfs entry and that UUID can be used to evict the client, like:
+ </para>
+<screen>
+client$ lctl get_param llite.testfs-*.uuid
+llite.testfs-ffff991ae1992000.uuid=dd599d28-0a85-a9e4-82cd-dc6357a42c77
+oss# lctl set_param obdfilter.testfs-*.evict_client=dd599d28-0a85-a9e4-82cd-dc6357a42c77
+mds# lctl set_param mdt.testfs-*.evict_client=dd599d28-0a85-a9e4-82cd-dc6357a42c77
+</screen>
</section>
</section>
<para>Which server node it was communicating with, and so on.</para>
</listitem>
</itemizedlist>
- <para>Lustre logs are dumped to <literal>/proc/sys/lnet/debug_path</literal>.</para>
+ <para>Lustre logs are dumped to the pathname stored in the parameter
+ <literal>lnet.debug_path</literal>.</para>
<para>Collect the first group of messages related to a problem, and any messages that precede "LBUG" or "assertion failure" errors. Messages that mention server nodes (OST or MDS) are specific to that server; you must collect similar messages from the relevant server console logs.</para>
<para>Another Lustre debug log holds information for a short period of time for action by the
Lustre software, which, in turn, depends on the processes on the Lustre node. Use the
<para>If the SCSI devices are inaccessible to the Lustre file system
at the block device level, then <literal>ldiskfs</literal> remounts
the device read-only to prevent file system corruption. This is a normal
- behavior. The status in <literal>/proc/fs/lustre/health_check</literal>
+ behavior. The status in the parameter <literal>health_check</literal>
also shows "not healthy" on the affected nodes.</para>
<para>To determine what caused the "not healthy" condition:</para>
<itemizedlist>
events across all CPTs. This may balance load better across the CPU but
can incur a cross CPU overhead.</para>
<para>The current policy can be changed by an administrator with
- <literal>echo
- <replaceable>value</replaceable>>
- /proc/sys/lnet/portal_rotor</literal>. There are four options for
+ <literal>lctl set_param portal_rotor=value</literal>.
+ There are four options for
<literal>
<replaceable>value</replaceable>
</literal>:</para>
<para>
<emphasis role="bold">Client-side:</emphasis>
</para>
- <screen>
-/proc/fs/lustre/llite/lustre-*
-</screen>
+ <screen>llite.<replaceable>fsname</replaceable>-*</screen>
<para>
<literal>contention_seconds</literal>-
<literal>llite</literal> inode remembers its contended state for the
<emphasis role="bold">Client-side statistics:</emphasis>
</para>
<para>The
- <literal>/proc/fs/lustre/llite/lustre-*/stats</literal> file has new
- rows for lockless I/O statistics.</para>
+ <literal>llite.<replaceable>fsname</replaceable>-*.stats</literal>
+ parameter has several entries for lockless I/O statistics.</para>
<para>
<literal>lockless_read_bytes</literal> and
<literal>lockless_write_bytes</literal>- To count the total bytes read
</listitem>
</orderedlist>
<para>If a Lustre file system administrator wants to explore this approach
- further, per-OST disk-usage statistics can be found under
- <literal>/proc/fs/lustre/osc/*/rpc_stats</literal></para>
+ further, per-OST disk-usage statistics can be found in the
+ <literal>osc.*.rpc_stats</literal> parameter file.</para>
</section>
<section xml:id="dbdoclet.50438211_80295">
<title>
</section>
<section remap="h5">
<title>Files</title>
- <para>The l_getidentity files are located at:</para>
- <screen>/proc/fs/lustre/mdt/${FSNAME}-MDT{xxxx}/identity_upcall</screen>
+ <para>The parameter to set the <literal>l_getidentity</literal> path is:
+ </para>
+<screen>mds# lctl set_param -P mdt.*-MDT*.identity_upcall=<replaceable>path</replaceable>
+</screen>
</section>
</section>
<section xml:id="dbdoclet.50438219_38274">
</section>
<section remap="h5">
<title>Setting Parameters with lctl</title>
- <para>Lustre parameters are not always accessible using the procfs interface, as it is platform-specific. As a solution, lctl {get,set}_param has been introduced as a platform-independent interface to the Lustre tunables. Avoid direct references to /proc/{fs,sys}/{lustre,lnet}. For future portability, use lctl {get,set}_param .</para>
- <para>When the file system is running, use the <literal>lctl set_param</literal> command on the affected node(s) to <emphasis>temporarily</emphasis> set parameters (mapping to items in /proc/{fs,sys}/{lnet,lustre}). The <literal>lctl set_param</literal> command uses this syntax:</para>
+ <para>Lustre parameters are not always accessible using the procfs
+ interface, as it is platform-specific. As a solution,
+ <literal>lctl {get,set}_param</literal> provides a platform-independent
+ interface to the Lustre tunables. Avoid any direct references to
+ <literal>/proc</literal> and <literal>/sys</literal> files in scripts.
+ For future portability, instead use lctl {get,set}_param, which handles
+ these details internally.</para>
+ <para>When the file system is running, use the
+ <literal>lctl set_param</literal> command on the affected node(s) to
+ <emphasis>temporarily</emphasis> set parameters (mapping to items in).
+ The <literal>lctl set_param</literal> command uses this syntax:</para>
<screen>lctl set_param [-n] [-P] [-d] <replaceable>obdtype.obdname.property</replaceable>=<replaceable>value</replaceable></screen>
<para>For example:</para>
- <screen>mds# lctl set_param mdt.testfs-MDT0000.identity_upcall=NONE</screen>
- <para condition='l25'>Use <literal>-P</literal> option to set parameters permanently. Option <literal>-d </literal>deletes permanent parameters. For example:
- <screen>mgs# lctl set_param -P mdt.testfs-MDT0000.identity_upcall=NONE
+<screen>mds# lctl set_param mdt.testfs-MDT0000.identity_upcall=NONE</screen>
+ <para condition='l25'>Use <literal>-P</literal> option to set parameters
+ permanently. Option <literal>-d </literal>deletes permanent parameters.
+ For example:
+<screen>
+mgs# lctl set_param -P mdt.testfs-MDT0000.identity_upcall=NONE
mgs# lctl set_param -P -d mdt.testfs-MDT0000.identity_upcall</screen></para>
- <para>Many permanent parameters can be set with <literal>lctl conf_param</literal>. In general, <literal>lctl conf_param</literal> can be used to specify any OBD device parameter settable in a /proc/fs/lustre file. The <literal>lctl conf_param</literal> command must be run on the MGS node, and uses this syntax:</para>
+ <para>Many permanent parameters can be set with the
+ <literal>lctl conf_param</literal> utility. In general,
+ <literal>lctl conf_param</literal> can be used to specify any OBD
+ device parameter settable in a /proc/fs/lustre file. The
+ <literal>lctl conf_param</literal> command must be run on the MGS node,
+ and uses this syntax:</para>
<screen><replaceable>obd|fsname</replaceable>.obdtype.property=<replaceable>value</replaceable>) </screen>
<para>For example:</para>
<screen>mgs# lctl conf_param testfs-MDT0000.mdt.identity_upcall=NONE
<para>The lustre_req_history.sh utility (run from a client), assembles as much Lustre RPC request history as possible from the local node and from the servers that were contacted, providing a better picture of the coordinated network activity.</para>
</section>
<section remap="h3">
- <title>More /proc Statistics for Application Profiling</title>
+ <title>More Statistics for Application Profiling</title>
<para>The following utilities provide additional statistics.</para>
<para><literal>vfs_ops_stats</literal></para>
- <para>The client vfs_ops_stats utility tracks Linux VFS operation calls into Lustre for a single PID, PPID, GID or everything.</para>
- <screen>/proc/fs/lustre/llite/*/vfs_ops_stats
-/proc/fs/lustre/llite/*/vfs_track_[pid|ppid|gid]
-</screen>
+ <para>The client vfs_ops_stats utility tracks Linux VFS operation calls
+ into Lustre for a single PID, PPID, GID or everything.</para>
+ <screen>llite.*.vfs_ops_stats llite.*.vfs_track_[pid|ppid|gid]</screen>
<para><literal>extents_stats</literal></para>
- <para>The client extents_stats utility shows the size distribution of I/O calls from the client (cumulative and by process).</para>
- <screen>/proc/fs/lustre/llite/*/extents_stats, extents_stats_per_process
-</screen>
+ <para>The client extents_stats utility shows the size distribution of
+ I/O calls from the client (cumulative and by process).</para>
+ <screen>llite.*.{extents_stats,extents_stats_per_process}</screen>
<para><literal>offset_stats</literal></para>
- <para>The client offset_stats utility shows the read/write seek activity of a client by offsets and ranges.</para>
- <screen>/proc/fs/lustre/llite/*/offset_stats
-</screen>
+ <para>The client offset_stats utility shows the read/write seek activity
+ of a client by offsets and ranges.</para>
+ <screen>llite.*.offset_stats</screen>
<para>Lustre includes per-client and improved MDT statistics:</para>
<itemizedlist>
<listitem>
<para>Each MDS and OSS now tracks LDLM and operations statistics for
every connected client, for comparisons and simpler collection of
distributed job statistics.</para>
- <screen>/proc/fs/lustre/mds|obdfilter/*/exports/
+ <screen>{mds,obdfilter}.*.exports
</screen>
<itemizedlist>
<listitem>
</itemizedlist>
<para>More detailed MDT operations statistics are collected for better
profiling.</para>
- <screen>/proc/fs/lustre/mdt/*/md_stats
+ <screen>mdt.*.md_stats
</screen>
</section>
<section remap="h3">
is enhanced to support verify and repair inconsistencies between multiple
MDTs.</para>
<para>Control and monitoring of LFSCK is through LFSCK and the
- <literal>/proc</literal> file system interfaces. LFSCK supports three types
+ <literal>lctl get_param</literal> command. LFSCK supports three types
of interface: switch interface, status interface, and adjustment interface.
These interfaces are detailed below.</para>
<section>
guarantee that
<literal>atime</literal> is kept coherent across the
cluster.)</para>
- <para>OSTs store a transient
+ <para>OSTs by default only hold a transient
<literal>atime</literal> that is updated when clients do read
requests. Permanent
- <literal>atime</literal> is written to the MDS when the file is
+ <literal>atime</literal> is written to the MDT when the file is
closed. However, on-disk atime is only updated if it is more
than 60 seconds old (
- <literal>/proc/fs/lustre/mds/*/max_atime_diff</literal>). The
- Lustre software considers the latest
- <literal>atime</literal> from all OSTs. If a
+ <literal>mdd.*.atime_diff</literal>).
+ </para>
+ <para condition='l2D'>In Lustre 2.14, it is possible to set
+ the OSTs to persistently store atime with each object, in
+ order to get more accurate persistent atime updates for files
+ that are open for a long time via the similarly-named
+ <literal>obdfilter.*.atime_diff</literal> parameter.
+ </para>
+ <para>
+ The client considers the latest <literal>atime</literal> from
+ all OSTs and MDTs. If a
<literal>setattr</literal> is set by user, then it is updated on
- both the MDS and OST, allowing the
+ both the MDT and OST, allowing the
<literal>atime</literal> to go backward.</para>
</entry>
</row>
git://git.whamcloud.com / doc / manual.git / commitdiff