Glossary.xml

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <glossary xmlns="http://docbook.org/ns/docbook"
   3  xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US">
   4   <title>Glossary</title>
   5   <glossdiv>
   6     <title>A</title>
   7     <glossentry xml:id="acl">
   8       <glossterm>ACL</glossterm>
   9       <glossdef>
  10         <para>Access control list. An extended attribute associated with a file
  11         that contains enhanced authorization directives.</para>
  12       </glossdef>
  13     </glossentry>
  14     <glossentry xml:id="ostfail">
  15       <glossterm>Administrative OST failure</glossterm>
  16       <glossdef>
  17         <para>A manual configuration change to mark an OST as unavailable, so
  18         that operations intended for that OST fail immediately with an I/O
  19         error instead of waiting indefinitely for OST recovery to
  20         complete</para>
  21       </glossdef>
  22     </glossentry>
  23   </glossdiv>
  24   <glossdiv>
  25     <title>C</title>
  26     <glossentry xml:id="completioncallback">
  27       <glossterm>Completion callback</glossterm>
  28       <glossdef>
  29         <para>An RPC made by the lock server on an OST or MDT to another
  30         system, usually a client, to indicate that the lock is now
  31         granted.</para>
  32       </glossdef>
  33     </glossentry>
  34     <glossentry xml:id="changelog">
  35       <glossterm>configlog</glossterm>
  36       <glossdef>
  37         <para>An llog file used in a node, or retrieved from a management
  38         server over the network with configuration instructions for the Lustre
  39         file system at startup time.</para>
  40       </glossdef>
  41     </glossentry>
  42     <glossentry xml:id="configlock">
  43       <glossterm>Configuration lock</glossterm>
  44       <glossdef>
  45         <para>A lock held by every node in the cluster to control configuration
  46         changes. When the configuration is changed on the MGS, it revokes this
  47         lock from all nodes. When the nodes receive the blocking callback, they
  48         quiesce their traffic, cancel and re-enqueue the lock and wait until it
  49         is granted again. They can then fetch the configuration updates and
  50         resume normal operation.</para>
  51       </glossdef>
  52     </glossentry>
  53   </glossdiv>
  54   <glossdiv>
  55     <title>D</title>
  56     <glossentry xml:id="defaultstripepattern">
  57       <glossterm>Default file layout</glossterm>
  58       <glossdef>
  59         <para>An extended attribute on the filesystem root directory that
  60         describes the default stripe count, stripe size, and layout pattern
  61         used for new files created in a file system. This can be amended by
  62         using a default file layout on a directory or a per-file layout.</para>
  63       </glossdef>
  64     </glossentry>
  65     <glossentry xml:id="directio">
  66       <glossterm>Direct I/O</glossterm>
  67       <glossdef>
  68         <para>A mechanism that can be used during read and write system calls
  69         to avoid memory cache overhead for large I/O requests. It bypasses the
  70         data copy between application and kernel memory, and avoids buffering
  71         the data in the client memory.</para>
  72       </glossdef>
  73     </glossentry>
  74     <glossentry xml:id="default_file_layout">
  75       <glossterm>Directory default file layout</glossterm>
  76       <glossdef>
  77         <para>An extended attribute that describes the default file layout used
  78         for new files created within that directory. This is also inherited by
  79         new subdirectories created in that directory at creation time.</para>
  80       </glossdef>
  81     </glossentry>
  82     <glossentry xml:id="DNE">
  83       <glossterm>Distributed Namespace Environment (DNE)</glossterm>
  84       <glossdef>
  85         <para>A collection of metadata targets serving a single file
  86           system namespace. Without DNE, Lustre file systems are limited to a
  87           single metadata target for the entire name space. Without the ability
  88           to distribute metadata load over multiple targets, Lustre file system
  89           performance may be limited. The DNE functionality has two types of
  90           scalability.  <emphasis>Remote Directories</emphasis> (DNE1) allows
  91           sub-directories to be serviced by an independent MDT(s), increasing
  92           aggregate metadata capacity and performance for independent sub-trees
  93           of the filesystem. This also allows performance isolation of workloads
  94           running in a specific sub-directory on one MDT from workloads on other
  95           MDTs. In Lustre 2.8 and later <emphasis>Striped Directories</emphasis>
  96           (DNE2) allows a single directory to be serviced by multiple MDTs.
  97         </para>
  98       </glossdef>
  99     </glossentry>
 100   </glossdiv>
 101   <glossdiv>
 102     <title>E</title>
 103     <glossentry xml:id="ea">
 104       <glossterm>EA</glossterm>
 105       <glossdef>
 106         <para>Extended attribute (also xattr). A small amount of metadata
 107         stored on a file that can be retrieved by a name associated with a
 108         particular inode. A Lustre file system uses EAs to store striping
 109         information (indicating the location of file data on OSTs). Examples
 110         of extended attributes are ACLs, striping information, and the FID
 111         of the file.</para>
 112       </glossdef>
 113     </glossentry>
 114     <glossentry xml:id="eviction">
 115       <glossterm>Eviction</glossterm>
 116       <glossdef>
 117         <para>The process of removing a client's state from the server if the
 118         client is unresponsive to server requests after a timeout or if server
 119         recovery fails. If a client is still running, it is required to flush
 120         the cache associated with the server when it becomes aware that it has
 121         been evicted.</para>
 122       </glossdef>
 123     </glossentry>
 124     <glossentry xml:id="export">
 125       <glossterm>Export</glossterm>
 126       <glossdef>
 127         <para>The state held by a server for a client that is sufficient to
 128         transparently recover all in-flight operations when a single failure
 129         occurs.</para>
 130       </glossdef>
 131     </glossentry>
 132     <glossentry>
 133       <glossterm>Extent</glossterm>
 134       <glossdef>
 135         <para>A range of contiguous bytes or blocks in a file that are
 136         addressed by a {start, length} tuple instead of individual block
 137         numbers.</para>
 138       </glossdef>
 139     </glossentry>
 140     <glossentry xml:id="extendloc">
 141       <glossterm>Extent lock</glossterm>
 142       <glossdef>
 143         <para>An LDLM lock used by the OSC to protect an extent in an OST
 144         object for concurrent control of read/write, file size acquisition, and
 145         truncation operations.</para>
 146       </glossdef>
 147     </glossentry>
 148   </glossdiv>
 149   <glossdiv>
 150     <title>F</title>
 151     <glossentry xml:id="failback">
 152       <glossterm>Failback</glossterm>
 153       <glossdef>
 154         <para>The failover process in which the default active server regains
 155         control from the backup server that had taken control of the
 156         service.</para>
 157       </glossdef>
 158     </glossentry>
 159     <glossentry xml:id="failoutost">
 160       <glossterm>Failout OST</glossterm>
 161       <glossdef>
 162         <para>An OST that is not expected to recover if it fails to answer
 163         client requests. A failout OST can be administratively failed, thereby
 164         enabling clients to return errors when accessing data on the failed OST
 165         without making additional network requests or waiting for OST recovery
 166         to complete.</para>
 167       </glossdef>
 168     </glossentry>
 169     <glossentry xml:id="failover">
 170       <glossterm>Failover</glossterm>
 171       <glossdef>
 172         <para>The process by which a standby computer server system takes over
 173         for an active computer server after a failure of the active node.
 174         Typically, the standby computer server gains exclusive access to a
 175         shared storage device between the two servers.</para>
 176       </glossdef>
 177     </glossentry>
 178     <glossentry xml:id="fid">
 179       <glossterm>FID</glossterm>
 180       <glossdef>
 181         <para>Lustre File Identifier. A 128-bit file system-unique identifier
 182         for a file or object in the file system. The FID structure contains a
 183         unique 64-bit sequence number (see
 184         <emphasis role="italic">FLDB</emphasis>), a 32-bit object ID (OID), and
 185         a 32-bit version number. The sequence number is unique across all
 186         Lustre targets (OSTs and MDTs).</para>
 187       </glossdef>
 188     </glossentry>
 189     <glossentry xml:id="fileset">
 190       <glossterm>Fileset</glossterm>
 191       <glossdef>
 192         <para>A group of files that are defined through a directory that
 193         represents the start point of a file system.</para>
 194       </glossdef>
 195     </glossentry>
 196     <glossentry xml:id="fldb">
 197       <glossterm>FLDB</glossterm>
 198       <glossdef>
 199         <para>FID Location Database. This database maps a sequence of FIDs to a
 200         specific target (MDT or OST), which manages the objects within the
 201         sequence. The FLDB is cached by all clients and servers in the file
 202         system, but is typically only modified when new servers are added to
 203         the file system.</para>
 204       </glossdef>
 205     </glossentry>
 206     <glossentry xml:id="flightgroup">
 207       <glossterm>Flight group</glossterm>
 208       <glossdef>
 209         <para>Group of I/O RPCs initiated by the OSC that are concurrently
 210         queued or processed at the OST. Increasing the number of RPCs in flight
 211         for high latency networks can increase throughput and reduce visible
 212         latency at the client.</para>
 213       </glossdef>
 214     </glossentry>
 215   </glossdiv>
 216   <glossdiv>
 217     <title>G</title>
 218     <glossentry xml:id="glimpsecallback">
 219       <glossterm>Glimpse callback</glossterm>
 220       <glossdef>
 221         <para>An RPC made by an OST or MDT to another system (usually a client)
 222         to indicate that a held extent lock should be surrendered. If the
 223         system is using the lock, then the system should return the object size
 224         and timestamps in the reply to the glimpse callback instead of
 225         cancelling the lock. Glimpses are introduced to optimize the
 226         acquisition of file attributes without introducing contention on an
 227         active lock.</para>
 228       </glossdef>
 229     </glossentry>
 230   </glossdiv>
 231   <glossdiv>
 232     <title>I</title>
 233     <glossentry xml:id="import">
 234       <glossterm>Import</glossterm>
 235       <glossdef>
 236         <para>The state held by the client for each target that it is
 237         connected to. It holds server NIDs, connection state, and uncommitted
 238         RPCs needed to fully recover a transaction sequence after a server
 239         failure and restart.</para>
 240       </glossdef>
 241     </glossentry>
 242     <glossentry xml:id="intentlock">
 243       <glossterm>Intent lock</glossterm>
 244       <glossdef>
 245         <para>A special Lustre file system locking operation in the Linux
 246         kernel. An intent lock combines a request for a lock with the full
 247         information to perform the operation(s) for which the lock was
 248         requested. This offers the server the option of granting the lock or
 249         performing the operation and informing the client of the operation
 250         result without granting a lock. The use of intent locks enables
 251         metadata operations (even complicated ones) to be implemented with a
 252         single RPC from the client to the server.</para>
 253       </glossdef>
 254     </glossentry>
 255   </glossdiv>
 256   <glossdiv>
 257     <title>L</title>
 258     <glossentry xml:id="lbug">
 259       <glossterm>LBUG</glossterm>
 260       <glossdef>
 261         <para>A fatal error condition detected by the software that halts
 262         execution of the kernel thread to avoid potential further corruption of
 263         the system state. It is printed to the console log and triggers a dump
 264         of the internal debug log. The system must be rebooted to clear this
 265         state.</para>
 266       </glossdef>
 267     </glossentry>
 268     <glossentry xml:id="ldlm">
 269       <glossterm>LDLM</glossterm>
 270       <glossdef>
 271         <para>Lustre Distributed Lock Manager.</para>
 272       </glossdef>
 273     </glossentry>
 274     <glossentry xml:id="lfs">
 275       <glossterm>lfs</glossterm>
 276       <glossdef>
 277         <para>The Lustre file system command-line utility that allows end users
 278         to interact with Lustre software features, such as setting or checking
 279         file striping or per-target free space. For more details, see
 280         <xref xmlns:xlink="http://www.w3.org/1999/xlink"
 281          linkend="userutilities.lfs" />.</para>
 282       </glossdef>
 283     </glossentry>
 284     <glossentry xml:id="lfsck">
 285       <glossterm>LFSCK</glossterm>
 286       <glossdef>
 287         <para>Lustre file system check. A distributed version of a disk file
 288         system checker. Normally,
 289         <literal>lfsck</literal> does not need to be run, except when file
 290         systems are damaged by events such as multiple disk failures and cannot
 291         be recovered using file system journal recovery.</para>
 292       </glossdef>
 293     </glossentry>
 294     <glossentry xml:id="llite">
 295       <glossterm>llite</glossterm>
 296       <glossdef>
 297         <para>Lustre lite. This term is in use inside code and in module names
 298         for code that is related to the Linux client VFS interface.</para>
 299       </glossdef>
 300     </glossentry>
 301     <glossentry xml:id="llog">
 302       <glossterm>llog</glossterm>
 303       <glossdef>
 304         <para>Lustre log. An efficient log data structure used internally by
 305         the file system for storing configuration and distributed transaction
 306         records. An
 307         <literal>llog</literal> is suitable for rapid transactional appends of
 308         records and cheap cancellation of records through a bitmap.</para>
 309       </glossdef>
 310     </glossentry>
 311     <glossentry xml:id="llogcatalog">
 312       <glossterm>llog catalog</glossterm>
 313       <glossdef>
 314         <para>Lustre log catalog. An
 315         <literal>llog</literal> with records that each point at an
 316         <literal>llog</literal>. Catalogs were introduced to give
 317         <literal>llogs</literal> increased scalability.
 318         <literal>llogs</literal> have an originator which writes records and a
 319         replicator which cancels records when the records are no longer
 320         needed.</para>
 321       </glossdef>
 322     </glossentry>
 323     <glossentry xml:id="lmv">
 324       <glossterm>LMV</glossterm>
 325       <glossdef>
 326         <para>Logical Metadata Volume. A module that implements a DNE
 327         client-side abstraction device. It allows a client to work with many
 328         MDTs without changes to the llite module. The LMV code forwards
 329         requests to the correct MDT based on name or directory striping
 330         information and merges replies into a single result to pass back to the
 331         higher
 332         <literal>llite</literal> layer that connects the Lustre file system with
 333         Linux VFS, supports VFS semantics, and complies with POSIX interface
 334         specifications.</para>
 335       </glossdef>
 336     </glossentry>
 337     <glossentry xml:id="lnd">
 338       <glossterm>LND</glossterm>
 339       <glossdef>
 340         <para>Lustre network driver. A code module that enables LNet support
 341         over particular transports, such as TCP and various kinds of InfiniBand
 342         networks.</para>
 343       </glossdef>
 344     </glossentry>
 345     <glossentry xml:id="lnet">
 346       <glossterm>LNet</glossterm>
 347       <glossdef>
 348         <para>Lustre networking. A message passing network protocol capable of
 349         running and routing through various physical layers. LNet forms the
 350         underpinning of LNETrpc.</para>
 351       </glossdef>
 352     </glossentry>
 353     <glossentry xml:id="lockclient">
 354       <glossterm>Lock client</glossterm>
 355       <glossdef>
 356         <para>A module that makes lock RPCs to a lock server and handles
 357         revocations from the server.</para>
 358       </glossdef>
 359     </glossentry>
 360     <glossentry xml:id="lockserver">
 361       <glossterm>Lock server</glossterm>
 362       <glossdef>
 363         <para>A service that is co-located with a storage target that manages
 364         locks on certain objects. It also issues lock callback requests, calls
 365         while servicing or, for objects that are already locked, completes lock
 366         requests.</para>
 367       </glossdef>
 368     </glossentry>
 369     <glossentry xml:id="lov">
 370       <glossterm>LOV</glossterm>
 371       <glossdef>
 372         <para>Logical Object Volume. The object storage analog of a logical
 373         volume in a block device volume management system, such as LVM or EVMS.
 374         The LOV is primarily used to present a collection of OSTs as a single
 375         device to the MDT and client file system drivers.</para>
 376       </glossdef>
 377     </glossentry>
 378     <glossentry xml:id="lustreclient">
 379       <glossterm>Lustre client</glossterm>
 380       <glossdef>
 381         <para>An operating instance with a mounted Lustre file system.</para>
 382       </glossdef>
 383     </glossentry>
 384     <glossentry xml:id="lustrefile">
 385       <glossterm>Lustre file</glossterm>
 386       <glossdef>
 387         <para>A file in the Lustre file system. The implementation of a Lustre
 388         file is through an inode on a metadata server that contains references
 389         to one or more objects on an OSSs.</para>
 390       </glossdef>
 391     </glossentry>
 392   </glossdiv>
 393   <glossdiv>
 394     <title>M</title>
 395     <glossentry xml:id="mballoc">
 396       <glossterm>mballoc</glossterm>
 397       <glossdef>
 398         <para>Multi-block allocator. Functionality in ldiskfs that enables the
 399         <literal>ldiskfs</literal> file system to allocate multiple blocks with
 400         a single request to the block allocator.</para>
 401       </glossdef>
 402     </glossentry>
 403     <glossentry xml:id="mdc">
 404       <glossterm>MDC</glossterm>
 405       <glossdef>
 406         <para>MetaData Client. A Lustre client component that sends metadata
 407         requests via RPC over LNet to the metadata target (MDT).</para>
 408       </glossdef>
 409     </glossentry>
 410     <glossentry xml:id="mdd">
 411       <glossterm>MDD</glossterm>
 412       <glossdef>
 413         <para>Metadata Disk Device. Lustre server component that interfaces
 414         with the underlying object storage device to manage the Lustre file
 415         system namespace (directories, file ownership, attributes).</para>
 416       </glossdef>
 417     </glossentry>
 418     <glossentry xml:id="mds">
 419       <glossterm>MDS</glossterm>
 420       <glossdef>
 421         <para>MetaData Server. The server node that is hosting the metadata
 422         target (MDT).</para>
 423       </glossdef>
 424     </glossentry>
 425     <glossentry xml:id="mdt">
 426       <glossterm>MDT</glossterm>
 427       <glossdef>
 428         <para>MetaData Target. A storage device containing the file system
 429         namespace that is made available over the network to a client. It
 430         stores filenames, attributes, and the layout of OST objects that store
 431         the file data.</para>
 432       </glossdef>
 433     </glossentry>
 434     <glossentry xml:id="mdt0">
 435       <glossterm>MDT0000</glossterm>
 436       <glossdef>
 437         <para>The metadata target storing the file system root directory, as
 438           well as some core services such as quota tables.  Multiple metadata
 439           targets are possible in the same file system. MDT0000 must be
 440           available for the file system to be accessible.</para>
 441       </glossdef>
 442     </glossentry>
 443     <glossentry xml:id="mgs">
 444       <glossterm>MGS</glossterm>
 445       <glossdef>
 446         <para>Management Service. A software module that manages the startup
 447         configuration and changes to the configuration. Also, the server node
 448         on which this system runs.</para>
 449       </glossdef>
 450     </glossentry>
 451   </glossdiv>
 452   <glossdiv>
 453     <title>N</title>
 454     <glossentry xml:id="nid">
 455       <glossterm>NID</glossterm>
 456       <glossdef>
 457         <para>Network IDentifier. Encodes the type, network number, and network
 458         address of a network interface on a node for use by the Lustre file
 459         system.</para>
 460       </glossdef>
 461     </glossentry>
 462     <glossentry xml:id="nodeaffinity">
 463       <glossterm>Node affinity</glossterm>
 464       <glossdef>
 465         <para>Node affinity describes the property of process threads to be
 466         affine to specific cores on a NUMA system. Without node affinity,
 467         an operating system scheduler may move threads across processors in
 468         a sub-optimal way that significantly reduces performance of the
 469         system overall.</para>
 470       </glossdef>
 471     </glossentry>
 472     <glossentry xml:id="nrs">
 473       <glossterm>NRS</glossterm>
 474       <glossdef>
 475         <para>Network Request Scheduler. A subcomponent of the PtlRPC layer,
 476         which specifies the order in which RPCs are handled by servers. This
 477         allows optimizing large numbers of incoming requests for disk access
 478         patterns, fairness between clients, and other administrator-selected
 479         policies.</para>
 480       </glossdef>
 481     </glossentry>
 482     <glossentry xml:id="numa">
 483       <glossterm>NUMA</glossterm>
 484       <glossdef>
 485         <para>Non-Uniform Memory Access. Describes a multi-processing
 486         architecture where the time taken to access specific memory differs
 487         depending on memory location relative to a given processor. Typically
 488         machines with multiple sockets are NUMA architectures.</para>
 489       </glossdef>
 490     </glossentry>
 491   </glossdiv>
 492   <glossdiv>
 493     <title>O</title>
 494     <glossentry xml:id="odb">
 495       <glossterm>OBD</glossterm>
 496       <glossdef>
 497         <para>Object-Based Device. The generic term for components in the
 498         Lustre software stack that can be configured on the client or server.
 499         Examples include MDC, OSC, LOV, LMV, MDT, and OST.</para>
 500       </glossdef>
 501     </glossentry>
 502     <glossentry xml:id="odbtype">
 503       <glossterm>OBD type</glossterm>
 504       <glossdef>
 505         <para>Module that can implement the Lustre object or metadata APIs.
 506         Examples of OBD types include the LOV, OSC and OSD.</para>
 507       </glossdef>
 508     </glossentry>
 509     <glossentry xml:id="objectstorage">
 510       <glossterm>Object storage</glossterm>
 511       <glossdef>
 512         <para>Refers to a storage-device API or protocol involving storage
 513         objects and offsets therein, rather than addressing storage by
 514         individual blocks.
 515         </para>
 516       </glossdef>
 517     </glossentry>
 518     <glossentry xml:id="opencache">
 519       <glossterm>opencache</glossterm>
 520       <glossdef>
 521         <para>A cache of open file handles. This is a performance enhancement
 522         for NFS and files that are opened repeatedly on a client.</para>
 523       </glossdef>
 524     </glossentry>
 525     <glossentry xml:id="orphanobjects">
 526       <glossterm>Orphan objects</glossterm>
 527       <glossdef>
 528         <para>OST objects to which no Lustre file points. Orphan objects
 529         can arise from crashes and are automatically removed by an
 530         <literal>llog</literal> recovery between the MDT and OST. When a client
 531         deletes a file, the MDT unlinks it from the namespace. If this is the
 532         last link, it will atomically add the OST objects into a per-OST
 533         <literal>llog</literal>(in case a crash occurrs) and then wait until
 534         the MDT unlink commits to disk. At this point, it is safe to destroy
 535         the OST objects. Once the OST object destroy is committed, the MDT
 536         <literal>llog</literal> records can be cancelled.</para>
 537       </glossdef>
 538     </glossentry>
 539     <glossentry xml:id="osc">
 540       <glossterm>OSC</glossterm>
 541       <glossdef>
 542         <para>Object Storage Client. The client module communicating to an OST
 543         mounted on an OSS.</para>
 544       </glossdef>
 545     </glossentry>
 546     <glossentry xml:id="osd">
 547       <glossterm>OSD</glossterm>
 548       <glossdef>
 549         <para>Object Storage Device. A generic, industry term for storage
 550         devices with a more extended interface than block-oriented devices such
 551         as disks. For the Lustre file system, this name is used to describe a
 552         software module that implements an object storage API in the kernel. It
 553         is also used to refer to an instance of an object storage device
 554         created by that driver. The OSD device is layered on a file system,
 555         either ldiskfs (ext4) or ZFS, with methods that implement create,
 556         destroy and other I/O operations on file inodes.</para>
 557       </glossdef>
 558     </glossentry>
 559     <glossentry xml:id="oss">
 560       <glossterm>OSS</glossterm>
 561       <glossdef>
 562         <para>Object Storage Server. A server OBD that provides network access
 563         between the client and local OSTs.</para>
 564       </glossdef>
 565     </glossentry>
 566     <glossentry xml:id="ost">
 567       <glossterm>OST</glossterm>
 568       <glossdef>
 569         <para>Object Storage Target. An OSD made accessible through a network
 570         protocol. Typically, an OST is associated with a unique OSD which, in
 571         turn is associated with a formatted disk file system on the server
 572         containing the data objects.</para>
 573       </glossdef>
 574     </glossentry>
 575     <glossentry xml:id="overstriping">
 576       <glossterm>Overstriping</glossterm>
 577       <glossdef>
 578         <para>Using wide striping for a file that allocates multiple objects
 579         in a file to each OST.  This allows the number of stripes to exceed
 580         the number of OSTs, and can improve scalability for IO and locking.
 581         </para>
 582       </glossdef>
 583     </glossentry>
 584   </glossdiv>
 585   <glossdiv>
 586     <title>P</title>
 587     <glossentry xml:id="pdirops">
 588       <glossterm>pdirops</glossterm>
 589       <glossdef>
 590         <para>A locking protocol in the Linux VFS layer that allows for
 591         directory operations performed in parallel.</para>
 592       </glossdef>
 593     </glossentry>
 594     <glossentry xml:id="pool">
 595       <glossterm>Pool</glossterm>
 596       <glossdef>
 597         <para>OST pools allows the administrator to associate a name with an
 598         arbitrary subset of OSTs in a Lustre cluster. A group of OSTs can be
 599         combined into a named pool with unique access permissions and stripe
 600         characteristics.</para>
 601       </glossdef>
 602     </glossentry>
 603     <glossentry xml:id="portal">
 604       <glossterm>Portal</glossterm>
 605       <glossdef>
 606         <para>A service address on an LNet NID that binds requests to a
 607         specific request service, such as an MDS, MGS, OSS, or LDLM. Services
 608         may listen on multiple portals to ensure that high priority messages
 609         are not queued behind many slow requests on another portal.</para>
 610       </glossdef>
 611     </glossentry>
 612     <glossentry xml:id="ptlrpc">
 613       <glossterm>PtlRPC</glossterm>
 614       <glossdef>
 615         <para>An RPC protocol layered on LNet. This protocol deals with
 616         stateful servers and has exactly-once semantics and built in support
 617         for recovery.</para>
 618       </glossdef>
 619     </glossentry>
 620   </glossdiv>
 621   <glossdiv>
 622     <title>R</title>
 623     <glossentry xml:id="recovery">
 624       <glossterm>Recovery</glossterm>
 625       <glossdef>
 626         <para>The process that re-establishes the connection state when a
 627         client that was previously connected to a server reconnects after the
 628         server restarts.</para>
 629       </glossdef>
 630     </glossentry>
 631     <glossentry xml:id="remotedirectories">
 632       <glossterm>Remote directory</glossterm>
 633       <glossdef>
 634         <para>A remote directory describes a feature of Lustre DNE where
 635         a subdirectory may be stored on a different MDT than the parent
 636         directory.  This is sometimes referred to as DNE1.</para>
 637       </glossdef>
 638     </glossentry>
 639     <glossentry xml:id="replay">
 640       <glossterm>Replay request</glossterm>
 641       <glossdef>
 642         <para>The concept of re-executing a server request after the server has
 643         lost information in its memory caches and shut down. The replay
 644         requests are retained by clients until the server(s) have confirmed
 645         that the data is persistent on disk. Only requests for which a client
 646         received a reply and were assigned a transaction number by the server
 647         are replayed. Requests that did not get a reply are resent.</para>
 648       </glossdef>
 649     </glossentry>
 650     <glossentry xml:id="resent">
 651       <glossterm>Resent request</glossterm>
 652       <glossdef>
 653         <para>An RPC request sent from a client to a server that has not had a
 654         reply from the server. This might happen if the request was lost on the
 655         way to the server, if the reply was lost on the way back from the
 656         server, or if the server crashes before or after processing the
 657         request. During server RPC recovery processing, resent requests are
 658         processed after replayed requests, and use the client RPC XID to
 659         determine if the resent RPC request was already executed on the
 660         server.</para>
 661       </glossdef>
 662     </glossentry>
 663     <glossentry xml:id="revocation">
 664       <glossterm>Revocation callback</glossterm>
 665       <glossdef>
 666         <para>Also called a "blocking callback". An RPC request made by the
 667         lock server (typically for an OST or MDT) to a lock client to revoke a
 668         granted DLM lock.</para>
 669       </glossdef>
 670     </glossentry>
 671     <glossentry xml:id="rootsquash">
 672       <glossterm>Root squash</glossterm>
 673       <glossdef>
 674         <para>A mechanism whereby the identity of a root user on a client
 675         system is mapped to a different identity on the server to avoid root
 676         users on clients from accessing or modifying root-owned files on the
 677         servers. This does not prevent root users on the client from assuming
 678         the identity of a non-root user, so should not be considered a robust
 679         security mechanism. Typically, for management purposes, at least one
 680         client system should not be subject to root squash.</para>
 681       </glossdef>
 682     </glossentry>
 683     <glossentry xml:id="routing">
 684       <glossterm>Routing</glossterm>
 685       <glossdef>
 686         <para>LNet routing between different networks and LNDs.</para>
 687       </glossdef>
 688     </glossentry>
 689     <glossentry xml:id="rpc">
 690       <glossterm>RPC</glossterm>
 691       <glossdef>
 692         <para>Remote Procedure Call. A network encoding of a request, often
 693         sent from a client to a server to perform a particular action.</para>
 694       </glossdef>
 695     </glossentry>
 696   </glossdiv>
 697   <glossdiv>
 698     <title>S</title>
 699     <glossentry xml:id="stripe">
 700       <glossterm>Stripe</glossterm>
 701       <glossdef>
 702         <para>A contiguous, logical extent of a Lustre file written to a single
 703         OST. Used synonymously with a single OST data object that makes up part
 704         of a file visible to user applications.</para>
 705       </glossdef>
 706     </glossentry>
 707     <glossentry xml:id="stripeddirectory" condition='l28'>
 708       <glossterm>Striped Directory</glossterm>
 709       <glossdef>
 710         <para>A striped directory is when metadata for files in a given
 711         directory are distributed evenly over multiple MDTs. Striped directories
 712         are only available in Lustre software version 2.8 or later.
 713         A user can create a striped directory to increase metadata
 714         performance of very large directories (e.g. 1M+ entries) by
 715         distributing the metadata requests in a single directory over
 716         two or more MDTs.  This is sometimes called DNE2.</para>
 717       </glossdef>
 718     </glossentry>
 719     <glossentry xml:id="stripesize">
 720       <glossterm>Stripe size</glossterm>
 721       <glossdef>
 722         <para>The maximum number of bytes that will be written to an OST object
 723         in a RAID0-striped Lustre file before the next object in the file's
 724         layout is used, when writing data sequentially to a file. Once a full
 725         stripe has been written to each of the objects in the layout, the first
 726         object will be written to again in round-robin fashion.</para>
 727       </glossdef>
 728     </glossentry>
 729     <glossentry xml:id="stripcount">
 730       <glossterm>Stripe count</glossterm>
 731       <glossdef>
 732         <para>The number of OSTs holding objects for a RAID0-striped Lustre
 733         file.</para>
 734       </glossdef>
 735     </glossentry>
 736   </glossdiv>
 737   <glossdiv>
 738     <title>T</title>
 739     <glossentry xml:id="t10">
 740       <glossterm>T10-PI</glossterm>
 741       <glossdef>
 742         <para>Checksum format defined by the T10 SCSI committee to store
 743         data checksums together with the data on supporting storage devices.
 744         </para>
 745       </glossdef>
 746     </glossentry>
 747     <glossentry xml:id="tbf">
 748       <glossterm>TBF</glossterm>
 749       <glossdef>
 750         <para>Token Bucket Filter.  NRS policy that assigns tokens to each
 751         rule proportional to the priority of RPCs submitted that match the
 752         rule.  When the tokens for a rule have all been consumed within a
 753         time period, any remaining RPCs matching that rule must wait until
 754         the next time period to be processed.
 755         </para>
 756       </glossdef>
 757     </glossentry>
 758   </glossdiv>
 759   <glossdiv>
 760     <title>W</title>
 761     <glossentry xml:id="widestriping">
 762       <glossterm>Wide striping</glossterm>
 763       <glossdef>
 764         <para>Strategy of using many OSTs to store stripes of a single file.
 765         This obtains maximum bandwidth access to a single file through parallel
 766         utilization of many OSTs. For more information about wide striping, see
 767
 768         <xref xmlns:xlink="http://www.w3.org/1999/xlink"
 769         linkend="wide_striping" />.</para>
 770       </glossdef>
 771     </glossentry>
 772   </glossdiv>
 773 </glossary>
 774 <!--
 775   vim:expandtab:shiftwidth=2:tabstop=8:
 776   -->