Glossary.xml

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