and the protocols used to implement them.
[glossary]
-back end file system::
-Storage on a server in support of the object store or of metadata is
-stored on the back end file system. The two available file systems are
-currently ldiskfs and ZFS.
+Object Storage Device (OSD)::
+The OSD is the storage on a server that holds objects or metadata. The
+two kinds of file system available ofr OSDs are ldiskfs and ZFS.
Client::
A Lustre client is a computer taking advantage of the services
system.
early reply::
-A message returned in response to a request message that allows the
-target to extend timeout values without otherwise indicating the
-request has progressed.
+A partial message reply returned in response to a request message
+that allows the target to indicate to the requestor to increase its
+timeout value without otherwise indicating the request has progressed.
export::
-The term for the per-client shared state information held by a server.
+The term for the per-client shared state information held by a
+server. See <<struct-obd-export>>.
extent:: A range of offsets in a file.
import::
-The term for the per-target shared state information held by a client.
+The term for the per-target shared state information held by a
+client. See <<struct_obd_import>>.
Inodes and Extended Attributes::
Metadata about a Lustre file is encoded in the extended attributes of
-an inode in the back-end file system on the MDS. Some of that
-information establishes the stripe layout of the file. The size of the
-stripe layout information varies among Lustre file systems. The amount
-of space reserved for layout information is a small as possible given
-the maximum stripe count possible on the file system. Clients, servers,
-and the distributed lock manager will all need to be aware of this
-size, which is communicated in the 'ocd_ibis_known' filed of the
-'obd_connect_data' structure.
+an inode on the MDT. Some of that information establishes the stripe
+layout of the file. The size of the stripe layout information may be
+different for each file. The amount of space reserved for layout
+information is a small as possible given the maximum stripe count on
+the file system. Clients, servers, and the distributed lock manager
+will all need to be aware of this size, which is communicated in the
+'ocd_max_easize' fieled of the <<struct-obd-connect-data>> structure.
LNet::
A lower level protocol employed by PtlRPC to abstract the mechanisms
A metadata server (MDS) is a computer responsible for running the
Lustre kernel services in support of managing the POSIX-compliant name
space and the indices associating files in that name space with the
-locations of their corresponding objects. As of v2.4 there can be
-multiple MDSs in a Lustre file system.
+locations of their corresponding objects. As of Lustre 2.4 there can be
+multiple MDSs in a single Lustre file system.
Metadata Target::
A metadata target (MDT) is the service provided by an MDS that
mediates the management of name space indices on the underlying file
-system hardware. As of v2.4 there can be multiple MDTs on an MDS.
+system hardware. As of Lustre 2.4 there can be multiple MDTs on an MDS.
+An MDT can be served by different MDS nodes at different times, but
+will only be available from a single MDS at any given time.
Object Based Disk::
Object Based Disk (OBD) is the term used for any target, MDT or OST.
Object Storage Target::
An object storage target (OST) is the service provided by an OSS that
mediates the placement of data objects on the specific underlying file
-system hardware. There can be multiple OSTs on a given OSS.
+system hardware. There can be multiple OSTs on a given OSS. An OST
+may be served by different OSS nodes at different times, but will
+only be available from one OSS at any given time.
protocol::
An agreed upon formalism for communicating between two entities, such
git://git.whamcloud.com / doc / protocol.git / blobdiff