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