<?xml version="1.0" encoding="utf-8"?>
<glossary xmlns="http://docbook.org/ns/docbook"
-xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US">
+ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US">
<title>Glossary</title>
<glossdiv>
<title>A</title>
</glossdiv>
<glossdiv>
<title>D</title>
- <glossentry xml:id="defaultstrippattern">
+ <glossentry xml:id="defaultstripepattern">
<glossterm>Default stripe pattern</glossterm>
<glossdef>
<para>Information in the LOV descriptor that describes the default
new subdirectories at the time they are created.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="DNE" condition='l24'>
- <glossterm>Distributed namespace (DNE)</glossterm>
- <glossdef>
- <para>A collection of metadata targets serving a single file
- system namespace. Prior to DNE, Lustre file systems were limited to a
- single metadata target for the entire name space. Without the ability
- to distribute metadata load over multiple targets, Lustre file system
- performance is limited. Lustre was enhanced with DNE functionality in
- two development phases. After completing the first phase of development
- in Lustre software version 2.4, <emphasis>Remote Directories</emphasis>
- allowed the metadata for sub-directories to be serviced by an
- independent MDT(s). After completing the second phase of development in
- Lustre software version 2.8, <emphasis>Striped Directories</emphasis>
- allowed files in a single directory to be serviced by multiple MDTs.
+ <glossentry xml:id="DNE">
+ <glossterm>Distributed Namespace Environment (DNE)</glossterm>
+ <glossdef>
+ <para>A collection of metadata targets serving a single file
+ system namespace. Without DNE, Lustre file systems are limited to a
+ single metadata target for the entire name space. Without the ability
+ to distribute metadata load over multiple targets, Lustre file system
+ performance may be limited. The DNE functionality has two types of
+ scalability. <emphasis>Remote Directories</emphasis> (DNE1) allows
+ sub-directories to be serviced by an independent MDT(s), increasing
+ aggregate metadata capacity and performance for independent sub-trees
+ of the filesystem. This also allows performance isolation of workloads
+ running in a specific sub-directory on one MDT from workloads on other
+ MDTs. In Lustre 2.8 and later <emphasis>Striped Directories</emphasis>
+ (DNE2) allows a single directory to be serviced by multiple MDTs.
</para>
</glossdef>
</glossentry>
<glossterm>EA</glossterm>
<glossdef>
<para>Extended attribute. A small amount of data that can be retrieved
- through a name (EA or attr) associated with a particular inode. A
+ through a name (EA or xattr) associated with a particular inode. A
Lustre file system uses EAs to store striping information (indicating
the location of file data on OSTs). Examples of extended attributes are
ACLs, striping information, and the FID of the file.</para>
to interact with Lustre software features, such as setting or checking
file striping or per-target free space. For more details, see
<xref xmlns:xlink="http://www.w3.org/1999/xlink"
- linkend="dbdoclet.50438206_94597" />.</para>
+ linkend="userutilities.lfs" />.</para>
</glossdef>
</glossentry>
<glossentry xml:id="lfsck">
<glossentry xml:id="lnd">
<glossterm>LND</glossterm>
<glossdef>
- <para>Lustre network driver. A code module that enables LNET support
+ <para>Lustre network driver. A code module that enables LNet support
over particular transports, such as TCP and various kinds of InfiniBand
networks.</para>
</glossdef>
</glossentry>
<glossentry xml:id="lnet">
- <glossterm>LNET</glossterm>
+ <glossterm>LNet</glossterm>
<glossdef>
<para>Lustre networking. A message passing network protocol capable of
- running and routing through various physical layers. LNET forms the
+ running and routing through various physical layers. LNet forms the
underpinning of LNETrpc.</para>
</glossdef>
</glossentry>
<glossterm>MDC</glossterm>
<glossdef>
<para>Metadata client. A Lustre client component that sends metadata
- requests via RPC over LNET to the metadata target (MDT).</para>
+ requests via RPC over LNet to the metadata target (MDT).</para>
</glossdef>
</glossentry>
<glossentry xml:id="mdd">
the file data.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="mdt0" condition='l24'>
- <glossterm>MDT0</glossterm>
+ <glossentry xml:id="mdt0">
+ <glossterm>MDT0000</glossterm>
<glossdef>
- <para>The metadata target for the file system root. Since Lustre
- software release 2.4, multiple metadata targets are possible in the
- same file system. MDT0 is the root of the file system, which must be
- available for the file system to be accessible.</para>
+ <para>The metadata target storing the file system root directory, as
+ well as some core services such as quota tables. Multiple metadata
+ targets are possible in the same file system. MDT0000 must be
+ available for the file system to be accessible.</para>
</glossdef>
</glossentry>
<glossentry xml:id="mgs">
<glossentry xml:id="nioapi">
<glossterm>NIO API</glossterm>
<glossdef>
- <para>A subset of the LNET RPC module that implements a library for
+ <para>A subset of the LNet RPC module that implements a library for
sending large network requests, moving buffers with RDMA.</para>
</glossdef>
</glossentry>
Examples include MDC, OSC, LOV, MDT, and OST.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="odbapi">
- <glossterm>OBD API</glossterm>
- <glossdef>
- <para>The programming interface for configuring OBD devices. This was
- formerly also the API for accessing object IO and attribute methods on
- both the client and server, but has been replaced by the OSD API in
- most parts of the code.</para>
- </glossdef>
- </glossentry>
<glossentry xml:id="odbtype">
<glossterm>OBD type</glossterm>
<glossdef>
Examples of OBD types include the LOV, OSC and OSD.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="odbfilter">
- <glossterm>Obdfilter</glossterm>
- <glossdef>
- <para>An older name for the OBD API data object operation device driver
- that sits between the OST and the OSD. In Lustre software release 2.4
- this device has been renamed OFD."</para>
- </glossdef>
- </glossentry>
<glossentry xml:id="objectstorage">
<glossterm>Object storage</glossterm>
<glossdef>
<glossentry xml:id="portal">
<glossterm>Portal</glossterm>
<glossdef>
- <para>A service address on an LNET NID that binds requests to a
+ <para>A service address on an LNet NID that binds requests to a
specific request service, such as an MDS, MGS, OSS, or LDLM. Services
may listen on multiple portals to ensure that high priority messages
are not queued behind many slow requests on another portal.</para>
<glossentry xml:id="ptlrpc">
<glossterm>PTLRPC</glossterm>
<glossdef>
- <para>An RPC protocol layered on LNET. This protocol deals with
+ <para>An RPC protocol layered on LNet. This protocol deals with
stateful servers and has exactly-once semantics and built in support
for recovery.</para>
</glossdef>
server restarts.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="remotedirectories" condition='l24'>
+ <glossentry xml:id="remotedirectories">
<glossterm>Remote directory</glossterm>
<glossdef>
- <para>A remote directory describes a feature of
- Lustre where metadata for files in a given directory may be
- stored on a different MDT than the metadata for the parent
- directory. Remote directories only became possible with the
- advent of DNE Phase 1, which arrived in Lustre version
- 2.4. Remote directories are available to system
- administrators who wish to provide individual metadata
- targets for individual workloads.</para>
+ <para>A remote directory describes a feature of Lustre where metadata
+ for files in a given directory may be stored on a different MDT than
+ the metadata for the parent directory. This is sometimes referred
+ to as DNE1.</para>
</glossdef>
</glossentry>
<glossentry xml:id="replay">
<glossentry xml:id="routing">
<glossterm>Routing</glossterm>
<glossdef>
- <para>LNET routing between different networks and LNDs.</para>
+ <para>LNet routing between different networks and LNDs.</para>
</glossdef>
</glossentry>
<glossentry xml:id="rpc">
<glossentry xml:id="stripeddirectory" condition='l28'>
<glossterm>Striped Directory</glossterm>
<glossdef>
- <para>A striped directory is a feature of Lustre
- software where metadata for files in a given directory are
- distributed evenly over multiple MDTs. Striped directories
+ <para>A striped directory is when metadata for files in a given
+ directory are distributed evenly over multiple MDTs. Striped directories
are only available in Lustre software version 2.8 or later.
- An administrator can use a striped directory to increase
- metadata performance by distributing the metadata requests
- in a single directory over two or more MDTs.</para>
+ A user can create a striped directory to increase metadata
+ performance of large directories by distributing the metadata
+ requests in a single directory over two or more MDTs.</para>
</glossdef>
</glossentry>
<glossentry xml:id="stridesize">
utilization of many OSTs. For more information about wide striping, see
<xref xmlns:xlink="http://www.w3.org/1999/xlink"
- linkend="section_syy_gcl_qk" />.</para>
+ linkend="wide_striping" />.</para>
</glossdef>
</glossentry>
</glossdiv>
</glossary>
+<!--
+ vim:expandtab:shiftwidth=2:tabstop=8:
+ -->
git://git.whamcloud.com / doc / manual.git / blobdiff