Hardware Reference
In-Depth Information
possibly overlapping read extent locks, or a combination of both read and
write locks.
Object I/O is specified by a triple of FID, start offset, length both by
clients and within the OST. The mapping from file extents to disk blocks is
managed entirely in the OSD. The underlying blocksize used for a given object
is therefore only relevant for I/O eciency and accounting purposes. As data
is written to an OST object, it grows in size like a regular data file and OST
objects may be sparse for some or all of their lifetime depending on the I/O
pattern of the application.
8.2.7 Management Server
The Management Server (MGS) stores and manages one or more file
system-wide configurations for both the client and server nodes. Clients spec-
ify the MGS hostname (for TCP networks) or NID (for any network) as part
of the mount device name in order to locate the MGS node, and the file sys-
tem name (fsname) is used to locate the configuration log for that file system.
The MGS typically stores its configuration logs and other state in a separate
OSD device, but it may also share the MDT storage if required. The MGS
also notifies clients of configuration changes and server restarts.
8.2.8 Client
The Lustre client is responsible for combining the data and index objects
exported by the data and metadata storage targets that make up a cluster
of Lustre servers into a single coherent POSIX-compliant file system. Since
this aggregation is done at the client, and since extent metadata is handled
locally by storage targets, non-contending data access at the POSIX level
can be mapped to non-contending data access at the object level, leading to
near-linear scaling of I/O performance.
The file system root FID is retrieved from MDT0 during mount. When
looking up any filename, the client sends the MDS an RPC to get a lock on
the parent directory. This request will either be a read lock with a lookup
intent, or a write lock with a create intent, and includes the filename to be
resolved. For create intents, the request will also contain a client-generated
FID for the new file. Resolving the intent on the MDS allows it to avoid
contention on the directory lock.
The MDS will resolve the lock intent locally, and instead return a DLM
lock on the new or existing child object FID to the client, along with all of the
metadata attributes and object layout (if a regular file). If the file was newly
created, the MDS will allocate OST objects for the file layout at open time
so that no further communication is needed with the MDS during I/O.
The file layout contains a data access pattern and the OST object FID(s),
which allows the client to access the file data directly from the OSTs. Each file
has a unique layout, and may be set by the user or application. The client is
