4 Here are some common terms used in discussing Lustre, POSIX semantics,
5 and the protocols used to implement them.
9 Storage on a server in support of the object store or of metadata is
10 stored on the back end file system. The two available file systems are
11 currently ldiskfs and ZFS.
14 A Lustre client is a computer taking advantage of the services
15 provided by MDSs and OSSs to assemble a POSIX-compliant file system
16 with its namespace and data storage capabilities.
18 Distributed Lock Manager::
19 The distributed lock manager (DLM, often referred to as the Lustre
20 Distributed Lock Manager, or LDLM) is the service that enforces a
21 consistent (cache-coherent) view of the data objects in the file
25 A message returned in response to a request message that allows the
26 target to extend timeout values without otherwise indicating the
27 request has progressed.
30 The term for the per-client shared state information held by a server.
32 extent:: A range of offsets in a file.
35 The term for the per-target shared state information held by a client.
37 Inodes and Extended Attributes::
38 Metadata about a Lustre file is encoded in the extended attributes of
39 an inode in the back-end file system on the MDS. Some of that
40 information establishes the stripe layout of the file. The size of the
41 stripe layout information varies among Lustre file systems. The amount
42 of space reserved for layout information is a small as possible given
43 the maximum stripe count possible on the file system. Clients, servers,
44 and the distributed lock manager will all need to be aware of this
45 size, which is communicated in the 'ocd_ibis_known' filed of the
46 'obd_connect_data' structure.
49 A lower level protocol employed by PtlRPC to abstract the mechanisms
50 provided by various hardware centric protocols, such as TCP or
56 The log subsystem (LOG) is something I have no idea about right now.
58 Logical Object Volume::
59 The logical object volume (LOV) layer abstracts the targets on a server.
62 The Management Server (MGS) maintains an understanding of the other
63 servers, targets, and client in the Lustre file system. It holds their
64 identities and keeps track of disconnections and reconnections in
65 order to support imperative recovery.
68 A metadata server (MDS) is a computer responsible for running the
69 Lustre kernel services in support of managing the POSIX-compliant name
70 space and the indices associating files in that name space with the
71 locations of their corresponding objects. As of v2.4 there can be
72 multiple MDSs in a Lustre file system.
75 A metadata target (MDT) is the service provided by an MDS that
76 mediates the management of name space indices on the underlying file
77 system hardware. As of v2.4 there can be multiple MDTs on an MDS.
80 Object Based Disk (OBD) is the term used for any target, MDT or OST.
82 Object Storage Server::
83 An object storage server (OSS) is a computer responsible for running
84 Lustre kernel services in support of managing bulk data objects on the
85 underlying storage. There can be multiple OSSs in a Lustre file
88 Object Storage Target::
89 An object storage target (OST) is the service provided by an OSS that
90 mediates the placement of data objects on the specific underlying file
91 system hardware. There can be multiple OSTs on a given OSS.
94 An agreed upon formalism for communicating between two entities, such
95 as between two servers or between a client and a server.
98 The protocol (or set of protocols) implemented via RPCs that is (are)
99 employed by Lustre to communicate between its clients and servers.
101 Remote Procedure Call::
102 A mechanism for implementing operations involving one computer acting
103 on the behalf of another (RPC).
106 A computer that provides a service. For example, management (MGS),
107 Metadata (MDS), or object storage (OSS) services in support of a
111 Storage available to be served, such as an OST or an MDT. Also the
112 service being provided.
114 UUID:: A universally unique identifier.