Before any other interaction can take place between a client and a
Lustre file system the client must 'mount' the file system, and Lustre
-services must already be in place (on the servers). A file system
-mount may be initiated at the Linux shell command line, which in turn
-invokes the 'mount()' system call. Kernel modules for Lustre
-exchange a series of messages with the servers, beginning with
-messages that retrieve details about the file system from the
+services must already be started on the servers. A file system
+mount may be initiated via the 'mount()' system call, passing the
+name of the MGS and Lustre filesystem to the kernel. The Lustre
+client exchanges a series of messages with the servers, beginning with
+messages that retrieve the file system configuration <<llog>> from the
management server (MGS). This provides the client with the identities
of all the metadata servers (MDSs) and targets (MDTs) as well as all
the object storage servers (OSSs) and targets (OSTs). The client then
again the server has an export for each client that has connected to
it. There a separate export for each client for each target.
-The client begins by carrying out the MGS_CONNECT Lustre operation,
-which establishes the connection (creates the import and the export)
-between the client and the MGS. The connect message from the client
-includes a 'handle' to uniquely identify itself (subsequent messages
-to the LDLM will refer to that client-handle). The connection data
-from the client also proposes the set of <<connect-flags,connection
-flags>> appropriate to connecting to an MGS.
+The client begins by carrying out the <<mgs-connect-rpc,MGS_CONNECT>>
+Lustre operation, which establishes the connection (creates the
+import and the export) between the client and the MGS. The connect
+message from the client includes a 'lustre_handle' to uniquely
+identify itself. Subsequent request messages to the MGS will refer
+to that client-handle to verify that the client has already connected.
+The connection data from the client also proposes the set of
+<<connect-flags,connection flags>> appropriate to connecting to an MGS.
.Flags for the client connection to an MGS
[options="header"]
information for the file system from the MGS in four stages. First,
the two exchange messages establishing the file system wide security
policy that will be followed in all subsequent communications. Second,
-the client gets a bitmap instructing it as to which among the
+the client gets a configuration <<llog>> starting with a bitmap
+instructing it as to which among the
configuration records on the MGS it needs. Third, reading those
records from the MGS gives the client the list of all the servers and
targets it will need to communicate with. Fourth, the client reads
-cluster wide configuration data (the sort that might be set at the
+the cluster wide configuration data (the sort that might be set at the
client command line with a 'lctl conf_param' command). The following
paragraphs go into these four stages in more detail.
git://git.whamcloud.com / doc / protocol.git / blobdiff