<glossdiv>
<title>D</title>
<glossentry xml:id="defaultstripepattern">
- <glossterm>Default stripe pattern</glossterm>
+ <glossterm>Default file layout</glossterm>
<glossdef>
- <para>Information in the LOV descriptor that describes the default
- stripe count, stripe size, and layout pattern used for new files in a
- file system. This can be amended by using a directory stripe descriptor
- or a per-file stripe descriptor.</para>
+ <para>An extended attribute on the filesystem root directory that
+ describes the default stripe count, stripe size, and layout pattern
+ used for new files created in a file system. This can be amended by
+ using a default file layout on a directory or a per-file layout.</para>
</glossdef>
</glossentry>
<glossentry xml:id="directio">
the data in the client memory.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="dirstripdesc">
- <glossterm>Directory stripe descriptor</glossterm>
+ <glossentry xml:id="default_file_layout">
+ <glossterm>Directory default file layout</glossterm>
<glossdef>
- <para>An extended attribute that describes the default stripe pattern
+ <para>An extended attribute that describes the default file layout used
for new files created within that directory. This is also inherited by
- new subdirectories at the time they are created.</para>
+ new subdirectories created in that directory at creation time.</para>
</glossdef>
</glossentry>
<glossentry xml:id="DNE">
<glossentry xml:id="ea">
<glossterm>EA</glossterm>
<glossdef>
- <para>Extended attribute. A small amount of data that can be retrieved
- 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>
+ <para>Extended attribute (also xattr). A small amount of metadata
+ stored on a file that can be retrieved by a name 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>
</glossdef>
</glossentry>
<glossentry xml:id="eviction">
<glossentry xml:id="extendloc">
<glossterm>Extent lock</glossterm>
<glossdef>
- <para>An LDLM lock used by the OSC to protect an extent in a storage
+ <para>An LDLM lock used by the OSC to protect an extent in an OST
object for concurrent control of read/write, file size acquisition, and
truncation operations.</para>
</glossdef>
<glossentry xml:id="fldb">
<glossterm>FLDB</glossterm>
<glossdef>
- <para>FID location database. This database maps a sequence of FIDs to a
+ <para>FID Location Database. This database maps a sequence of FIDs to a
specific target (MDT or OST), which manages the objects within the
sequence. The FLDB is cached by all clients and servers in the file
system, but is typically only modified when new servers are added to
<glossentry xml:id="lmv">
<glossterm>LMV</glossterm>
<glossdef>
- <para>Logical metadata volume. A module that implements a DNE
+ <para>Logical Metadata Volume. A module that implements a DNE
client-side abstraction device. It allows a client to work with many
MDTs without changes to the llite module. The LMV code forwards
requests to the correct MDT based on name or directory striping
<glossentry xml:id="lov">
<glossterm>LOV</glossterm>
<glossdef>
- <para>Logical object volume. The object storage analog of a logical
+ <para>Logical Object Volume. The object storage analog of a logical
volume in a block device volume management system, such as LVM or EVMS.
The LOV is primarily used to present a collection of OSTs as a single
device to the MDT and client file system drivers.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="lovdes">
- <glossterm>LOV descriptor</glossterm>
- <glossdef>
- <para>A set of configuration directives which describes which nodes are
- OSS systems in the Lustre cluster and providing names for their
- OSTs.</para>
- </glossdef>
- </glossentry>
<glossentry xml:id="lustreclient">
<glossterm>Lustre client</glossterm>
<glossdef>
<glossdef>
<para>A file in the Lustre file system. The implementation of a Lustre
file is through an inode on a metadata server that contains references
- to a storage object on OSSs.</para>
+ to one or more objects on an OSSs.</para>
</glossdef>
</glossentry>
</glossdiv>
<glossentry xml:id="mballoc">
<glossterm>mballoc</glossterm>
<glossdef>
- <para>Multi-block allocate. Functionality in ext4 that enables the
+ <para>Multi-block allocator. Functionality in ldiskfs that enables the
<literal>ldiskfs</literal> file system to allocate multiple blocks with
a single request to the block allocator.</para>
</glossdef>
<glossentry xml:id="mdc">
<glossterm>MDC</glossterm>
<glossdef>
- <para>Metadata client. A Lustre client component that sends metadata
+ <para>MetaData Client. A Lustre client component that sends metadata
requests via RPC over LNet to the metadata target (MDT).</para>
</glossdef>
</glossentry>
<glossentry xml:id="mdd">
<glossterm>MDD</glossterm>
<glossdef>
- <para>Metadata disk device. Lustre server component that interfaces
+ <para>Metadata Disk Device. Lustre server component that interfaces
with the underlying object storage device to manage the Lustre file
system namespace (directories, file ownership, attributes).</para>
</glossdef>
<glossentry xml:id="mds">
<glossterm>MDS</glossterm>
<glossdef>
- <para>Metadata server. The server node that is hosting the metadata
+ <para>MetaData Server. The server node that is hosting the metadata
target (MDT).</para>
</glossdef>
</glossentry>
<glossentry xml:id="mdt">
<glossterm>MDT</glossterm>
<glossdef>
- <para>Metadata target. A storage device containing the file system
+ <para>MetaData Target. A storage device containing the file system
namespace that is made available over the network to a client. It
stores filenames, attributes, and the layout of OST objects that store
the file data.</para>
<glossentry xml:id="mgs">
<glossterm>MGS</glossterm>
<glossdef>
- <para>Management service. A software module that manages the startup
+ <para>Management Service. A software module that manages the startup
configuration and changes to the configuration. Also, the server node
on which this system runs.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="mountconf">
- <glossterm>mountconf</glossterm>
- <glossdef>
- <para>The Lustre configuration protocol that formats disk file systems
- on servers with the
- <literal>mkfs.lustre</literal> program, and prepares them for automatic
- incorporation into a Lustre cluster. This allows clients to be
- configured and mounted with a simple
- <literal>mount</literal> command.</para>
- </glossdef>
- </glossentry>
</glossdiv>
<glossdiv>
<title>N</title>
<glossentry xml:id="nid">
<glossterm>NID</glossterm>
<glossdef>
- <para>Network identifier. Encodes the type, network number, and network
+ <para>Network IDentifier. Encodes the type, network number, and network
address of a network interface on a node for use by the Lustre file
system.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="nioapi">
- <glossterm>NIO API</glossterm>
- <glossdef>
- <para>A subset of the LNet RPC module that implements a library for
- sending large network requests, moving buffers with RDMA.</para>
- </glossdef>
- </glossentry>
- <glossentry xml:id="nodeaffdef">
+ <glossentry xml:id="nodeaffinity">
<glossterm>Node affinity</glossterm>
<glossdef>
- <para>Node affinity describes the property of a multi-threaded
- application to behave sensibly on multiple cores. Without the property
- of node affinity, an operating scheduler may move application threads
- across processors in a sub-optimal way that significantly reduces
- performance of the application overall.</para>
+ <para>Node affinity describes the property of process threads to be
+ affine to specific cores on a NUMA system. Without node affinity,
+ an operating system scheduler may move threads across processors in
+ a sub-optimal way that significantly reduces performance of the
+ system overall.</para>
</glossdef>
</glossentry>
<glossentry xml:id="nrs">
<glossterm>NRS</glossterm>
<glossdef>
- <para>Network request scheduler. A subcomponent of the PTLRPC layer,
- which specifies the order in which RPCs are handled at servers. This
+ <para>Network Request Scheduler. A subcomponent of the PtlRPC layer,
+ which specifies the order in which RPCs are handled by servers. This
allows optimizing large numbers of incoming requests for disk access
patterns, fairness between clients, and other administrator-selected
policies.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="NUMAdef">
+ <glossentry xml:id="numa">
<glossterm>NUMA</glossterm>
<glossdef>
- <para>Non-uniform memory access. Describes a multi-processing
- architecture where the time taken to access given memory differs
+ <para>Non-Uniform Memory Access. Describes a multi-processing
+ architecture where the time taken to access specific memory differs
depending on memory location relative to a given processor. Typically
machines with multiple sockets are NUMA architectures.</para>
</glossdef>
<glossentry xml:id="odb">
<glossterm>OBD</glossterm>
<glossdef>
- <para>Object-based device. The generic term for components in the
+ <para>Object-Based Device. The generic term for components in the
Lustre software stack that can be configured on the client or server.
- Examples include MDC, OSC, LOV, MDT, and OST.</para>
+ Examples include MDC, OSC, LOV, LMV, MDT, and OST.</para>
</glossdef>
</glossentry>
<glossentry xml:id="odbtype">
<glossterm>Object storage</glossterm>
<glossdef>
<para>Refers to a storage-device API or protocol involving storage
- objects. The two most well known instances of object storage are the
- T10 iSCSI storage object protocol and the Lustre object storage
- protocol (a network implementation of the Lustre object API). The
- principal difference between the Lustre protocol and T10 protocol is
- that the Lustre protocol includes locking and recovery control in the
- protocol and is not tied to a SCSI transport layer.</para>
+ objects and offsets therein, rather than addressing storage by
+ individual blocks.
+ </para>
</glossdef>
</glossentry>
<glossentry xml:id="opencache">
<glossterm>opencache</glossterm>
<glossdef>
<para>A cache of open file handles. This is a performance enhancement
- for NFS.</para>
+ for NFS and files that are opened repeatedly on a client.</para>
</glossdef>
</glossentry>
<glossentry xml:id="orphanobjects">
<glossterm>Orphan objects</glossterm>
<glossdef>
- <para>Storage objects to which no Lustre file points. Orphan objects
+ <para>OST objects to which no Lustre file points. Orphan objects
can arise from crashes and are automatically removed by an
<literal>llog</literal> recovery between the MDT and OST. When a client
deletes a file, the MDT unlinks it from the namespace. If this is the
last link, it will atomically add the OST objects into a per-OST
- <literal>llog</literal>(if a crash has occurred) and then wait until
- the unlink commits to disk. (At this point, it is safe to destroy the
- OST objects. Once the destroy is committed, the MDT
- <literal>llog</literal> records can be cancelled.)</para>
+ <literal>llog</literal>(in case a crash occurrs) and then wait until
+ the MDT unlink commits to disk. At this point, it is safe to destroy
+ the OST objects. Once the OST object destroy is committed, the MDT
+ <literal>llog</literal> records can be cancelled.</para>
</glossdef>
</glossentry>
<glossentry xml:id="osc">
<glossterm>OSC</glossterm>
<glossdef>
- <para>Object storage client. The client module communicating to an OST
- (via an OSS).</para>
+ <para>Object Storage Client. The client module communicating to an OST
+ mounted on an OSS.</para>
</glossdef>
</glossentry>
<glossentry xml:id="osd">
<glossterm>OSD</glossterm>
<glossdef>
- <para>Object storage device. A generic, industry term for storage
+ <para>Object Storage Device. A generic, industry term for storage
devices with a more extended interface than block-oriented devices such
as disks. For the Lustre file system, this name is used to describe a
software module that implements an object storage API in the kernel. It
is also used to refer to an instance of an object storage device
created by that driver. The OSD device is layered on a file system,
- with methods that mimic create, destroy and I/O operations on file
- inodes.</para>
+ either ldiskfs (ext4) or ZFS, with methods that implement create,
+ destroy and other I/O operations on file inodes.</para>
</glossdef>
</glossentry>
<glossentry xml:id="oss">
<glossterm>OSS</glossterm>
<glossdef>
- <para>Object storage server. A server OBD that provides access to local
- OSTs.</para>
+ <para>Object Storage Server. A server OBD that provides network access
+ between the client and local OSTs.</para>
</glossdef>
</glossentry>
<glossentry xml:id="ost">
<glossterm>OST</glossterm>
<glossdef>
- <para>Object storage target. An OSD made accessible through a network
+ <para>Object Storage Target. An OSD made accessible through a network
protocol. Typically, an OST is associated with a unique OSD which, in
turn is associated with a formatted disk file system on the server
containing the data objects.</para>
</glossdef>
</glossentry>
+ <glossentry xml:id="overstriping">
+ <glossterm>Overstriping</glossterm>
+ <glossdef>
+ <para>Using wide striping for a file that allocates multiple objects
+ in a file to each OST. This allows the number of stripes to exceed
+ the number of OSTs, and can improve scalability for IO and locking.
+ </para>
+ </glossdef>
+ </glossentry>
</glossdiv>
<glossdiv>
<title>P</title>
</glossdef>
</glossentry>
<glossentry xml:id="ptlrpc">
- <glossterm>PTLRPC</glossterm>
+ <glossterm>PtlRPC</glossterm>
<glossdef>
<para>An RPC protocol layered on LNet. This protocol deals with
stateful servers and has exactly-once semantics and built in support
<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. This is sometimes referred
- to as DNE1.</para>
+ <para>A remote directory describes a feature of Lustre DNE where
+ a subdirectory may be stored on a different MDT than the parent
+ directory. This is sometimes referred to as DNE1.</para>
</glossdef>
</glossentry>
<glossentry xml:id="replay">
<glossentry xml:id="rpc">
<glossterm>RPC</glossterm>
<glossdef>
- <para>Remote procedure call. A network encoding of a request.</para>
+ <para>Remote Procedure Call. A network encoding of a request, often
+ sent from a client to a server to perform a particular action.</para>
</glossdef>
</glossentry>
</glossdiv>
directory are distributed evenly over multiple MDTs. Striped directories
are only available in Lustre software version 2.8 or later.
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>
+ performance of very large directories (e.g. 1M+ entries) by
+ distributing the metadata requests in a single directory over
+ two or more MDTs. This is sometimes called DNE2.</para>
</glossdef>
</glossentry>
- <glossentry xml:id="stridesize">
+ <glossentry xml:id="stripesize">
<glossterm>Stripe size</glossterm>
<glossdef>
<para>The maximum number of bytes that will be written to an OST object
- before the next object in a file's layout is used when writing
- sequential data to a file. Once a full stripe has been written to each
- of the objects in the layout, the first object will be written to again
- in round-robin fashion.</para>
+ in a RAID0-striped Lustre file before the next object in the file's
+ layout is used, when writing data sequentially to a file. Once a full
+ stripe has been written to each of the objects in the layout, the first
+ object will be written to again in round-robin fashion.</para>
</glossdef>
</glossentry>
<glossentry xml:id="stripcount">
<glossdiv>
<title>T</title>
<glossentry xml:id="t10">
- <glossterm>T10 object protocol</glossterm>
+ <glossterm>T10-PI</glossterm>
<glossdef>
- <para>An object storage protocol tied to the SCSI transport layer. The
- Lustre file system does not use T10.</para>
+ <para>Checksum format defined by the T10 SCSI committee to store
+ data checksums together with the data on supporting storage devices.
+ </para>
+ </glossdef>
+ </glossentry>
+ <glossentry xml:id="tbf">
+ <glossterm>TBF</glossterm>
+ <glossdef>
+ <para>Token Bucket Filter. NRS policy that assigns tokens to each
+ rule proportional to the priority of RPCs submitted that match the
+ rule. When the tokens for a rule have all been consumed within a
+ time period, any remaining RPCs matching that rule must wait until
+ the next time period to be processed.
+ </para>
</glossdef>
</glossentry>
</glossdiv>
git://git.whamcloud.com / doc / manual.git / blobdiff