The mgs-connect-request.png diagram resembles this text art:
MGS_CONNECT:
- --request--------------------------------------------
- | ptlrpc_body | obd_uuid | obd_uuid | lustre_handle |
- -----------------------------------------------------
+ --request--------------------------------------------------
+ | ptlrpc_body | target_uuid | client_uuid | lustre_handle |
+ -----------------------------------------------------------
| obd_connect_data |
---------------------
//////////////////////////////////////////////////////////////////////
+See <<mgs-connect-rpc>>.
+
The client begins by carrying out the <<mgs-connect-rpc,MGS_CONNECT>>
-Lustre RPC, 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.
+Lustre RPC, 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
+(note that this is distinct from the 'pb_handle' field of the
+structure described in <<struct-ptlrpc-body>>, which will be 0 in a
+connection request). The target notes the 'lustre_handle' value in its
+'export'. 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"]
----------------------------------
//////////////////////////////////////////////////////////////////////
-The MGS's reply to the connection request will include the handle that
-the server and client will both use to identify this connection in
-subsequent messages. This is the 'connection-handle' (as opposed to
-the client-handle mentioned a moment ago). The MGS also replies with
-the same set of connection flags.
+The MGS's reply to the connection request will include the
+'lustre_handle' (in the 'ptlrpc_body' structure's 'pb_handle' field)
+that the client will use (in its 'pb_handle') to identify this target
+in subsequent messages. The MGS also replies with the same set of
+connection flags.
Once the connection is established the client gets configuration
information for the file system from the MGS in four stages. First,
------------------------------
//////////////////////////////////////////////////////////////////////
+See <<ldlm-enqueue-rpc>>.
+
The client seeks a 'concurrent read' lock on the MGS.
*4 - The MGS sends an LDLM_ENQUEUE reply to the client.*
*5 - The Client sends an LLOG_ORIGIN_HANDLE_CREATE to the MGS.*
-
.LLOG_ORIGIN_HANDLE_CREATE Request Packet Structure
image::llog-origin-handle-create-request.png["LLOG_ORIGIN_HANDLE_CREATE Request Packet Structure",height=50]
-------------------------------------
//////////////////////////////////////////////////////////////////////
+See <<llog-origin-handle-create>>.
+
The first LLOG_ORIGIN_HANDLE_CREATE operation asks
for the security configuration file ("lfs-sptlrpc"). <<security>>
discusses security.
== -2, ENOENT) indicated that there was no such file, so nothing
actually gets read.
-Next, the client gets a configuration <<llog>> starting with a bitmap
-instructing it as to which among the configuration records on the MGS
-it needs. Another LDLM_ENQUEUE and LLOG_ORIGIN_HANDLE_CREATE pair of
-operations identifies the configuration client data ("lfs-client")
-file.
+Next, the client gets a configuration log (See <<llog>>) starting with
+a bitmap instructing it as to which among the configuration records on
+the MGS it needs. Another LDLM_ENQUEUE and LLOG_ORIGIN_HANDLE_CREATE
+pair of operations identifies the configuration client data
+("lfs-client") file.
*7 - The Client sends an LDLM_ENQUEUE to the MGS.*
+See <<ldlm-enqueue-rpc>>.
+
The client again seeks a 'concurrent read' lock on the MGS.
*8 - The MGS sends an LDLM_ENQUEUE reply to the client.*
*9 - The Client sends an LLOG_ORIGIN_HANDLE_CREATE to the MGS.*
+See <<llog-origin-handle-create>>.
+
The client asks for the 'lfs-client' log file, which holds a bitmap
indicating the available configuration records.
----------------------------
//////////////////////////////////////////////////////////////////////
+See <<llog-origin-handle-read-header>>.
+
The client asks for that log file's header. The MGS stores
configuration data in log records. A header at the beginning of
"lfs-client" uses a bitmap to identify the log records that are
----------------------------
//////////////////////////////////////////////////////////////////////
+See <<llog-origin-handle-next-block>>.
+
The client asks for the configuration record.
*14 - The MGS sends an LLOG_ORIGIN_HANDLE_NEXT_BLOCK reply to the client.*
*15 - The Client sends an LDLM_ENQUEUE to the MGS.*
+See <<ldlm-enqueue-rpc>>.
+
The client again seeks a 'concurrent read' lock on the MGS.
*16 - The MGS sends an LDLM_ENQUEUE reply to the client.*
*17 - The Client sends an MGS_CONFIG_READ to the MGS.*
+.MGS_CONFIG_READ Request Packet Structure
+image::mgs-config-read-request.png["MGS_CONFIG_READ Request Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The mgs-config-read-request.png diagram resembles this text art:
+
+ MGS_CONFIG_READ:
+ --request------------------------
+ | ptlrpc_body | mgs_config_body |
+ ---------------------------------
+//////////////////////////////////////////////////////////////////////
+
+See <<mgs-config-read-rpc>>.
+
The client identifies the desired record in the 'lfs-cliir' file,
which contains the current details of the configuration for this file
system.
*18 - The MGS sends an MGS_CONFIG_READ reply to the client.*
+.MGS_CONFIG_READ Reply Packet Structure
+image::mgs-config-read-reply.png["MGS_CONFIG_READ Reply Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The mgs-config-read-reply.png diagram resembles this text art:
+
+ MGS_CONFIG_READ:
+ --reply-------------------------
+ | ptlrpc_body | mgs_config_res |
+ --------------------------------
+//////////////////////////////////////////////////////////////////////
+
The MGS responds with the actual configuration data. This gives the
client the list of all the servers and targets it will need to
communicate with.
*19 - The Client sends an LDLM_ENQUEUE to the MGS.*
+See <<ldlm-enqueue-rpc>>.
+
The client again seeks a 'concurrent read' lock on the MGS.
*20 - The MGS sends an LDLM_ENQUEUE reply to the client.*
*21 - The Client sends an LLOG_ORIGIN_HANDLE_CREATE to the MGS.*
+See <<llog-origin-handle-create>>.
+
The client asks for the 'params' log file.
*22 - The MGS sends an LLOG_ORIGIN_HANDLE_CREATE reply to the client.*
*23 - The Client sends an LLOG_ORIGIN_HANDLE_READ_HEADER to the MGS.*
+See <<llog-origin-handle-read-header>>.
+
The client asks for that log file's header.
*24 - The MGS sends an LLOG_ORIGIN_HANDLE_READ_HEADER reply to the client.*
The mds-connect-request.png diagram resembles this text art:
MDS_CONNECT:
- --request--------------------------------------------
- | ptlrpc_body | obd_uuid | obd_uuid | lustre_handle |
- -----------------------------------------------------
+ --request--------------------------------------------------
+ | ptlrpc_body | target_uuid | client_uuid | lustre_handle |
+ -----------------------------------------------------------
| obd_connect_data |
---------------------
//////////////////////////////////////////////////////////////////////
+See <<mds-connect-rpc>>.
+
As with the connect operation for the MGS, the connect message from
-the client includes a UUID to uniquely identify this connection, and
-subsequent messages to the lock manager on the server will refer to
-that UUID. The connection data from the client also proposes the set
+the client includes a 'lustre_handle' to uniquely identify this
+connection. The connection data from the client also proposes the set
of <<connect-flags,connection flags>> appropriate to connecting to an
MDS. The following are the flags always included.
The MDS replies to the connect message with a subset of the flags
proposed by the client, and the client notes those values in its
-import. The MDS's reply to the connection request will include a UUID
-that the server and client will both use to identify this connection
-in subsequent messages.
+import. As with the MGS, the MDS's reply to the connection request
+will include a 'lustre_handle' in the 'pb_handle' field that the
+client will use to identify this target in subsequent messages.
*3 - The Client sends an MDS_STATFS to the MDS.*
+.MDS_STATFS Request Packet Structure
+image::mds-statfs-request.png["MDS_STATFS Request Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The mds-statfs-request.png diagram resembles this text art:
+
+ MDS_STATFS:
+ --request------
+ | ptlrpc_body |
+ ---------------
+//////////////////////////////////////////////////////////////////////
+
+See <<mds-statfs-rpc>>.
+
The client next uses an MDS_STATFS operation to request 'statfs'
information from the target, and that data is returned in the reply
message. The actual fields closely resemble the results of a 'statfs'
*4 - The MDS sends an MDS_STATFS reply to the client.*
-The MDS replies witht eh 'statfs' information.
+.MDS_STATFS Reply Packet Structure
+image::mds-statfs-reply.png["MDS_STATFS Reply Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The mds-statfs-reply.png diagram resembles this text art:
+
+ MDS_STATFS:
+ --reply---------------------
+ | ptlrpc_body | obd_statfs |
+ ----------------------------
+//////////////////////////////////////////////////////////////////////
+
+The MDS replies with the 'statfs' information.
*5 - The Client sends an MDS_GETSTATUS to the MDS.*
+.MDS_GETSTATUS Request Packet Structure
+image::mds-getstatus-request.png["MDS_GETSTATUS Request Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The mds-getstatus-request.png diagram resembles this text art:
+
+ MDS_GETSTATUS:
+ --request-----------------
+ | ptlrpc_body | mdt_body |
+ --------------------------
+//////////////////////////////////////////////////////////////////////
+
+See <<mds-getstatus-rpc>>.
+
The client uses the MDS_GETSTATUS operation to request information
about the mount point of the file system.
*6 - The MDS sends an MDS_GETSTATUS reply to the client.*
+.MDS_GETSTATUS Reply Packet Structure
+image::mds-getstatus-reply.png["MDS_GETSTATUS Reply Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The mds-getstatus-reply.png diagram resembles this text art:
+
+ MDS_GETSTATUS:
+ --reply-------------------
+ | ptlrpc_body | mdt_body |
+ --------------------------
+//////////////////////////////////////////////////////////////////////
+
The server reply contains the 'fid' of the root directory of the file
system being mounted. If there is a security policy the capabilities
of that security policy are included in the reply.
*7 - The Client sends an MDS_GETATTR to the MDS.*
+.MDS_GETATTR Request Packet Structure
+image::mds-getattr-request.png["MDS_GETATTR Request Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The mds-getattr-request.png diagram resembles this text art:
+
+ MDS_GETATTR:
+ --request-------------------------------
+ | ptlrpc_body | mdt_body | lustre_capa |
+ ----------------------------------------
+//////////////////////////////////////////////////////////////////////
+
+See <<mds-getattr-rpc>>.
+
The client then uses the MDS_GETATTR operation to get get further
information about the root directory of the file system. The request
message includes the above fid.
*8 - The MDS sends an MDS_GETATTR reply to the client.*
+.MDS_GETATTR Reply Packet Structure
+image::mds-getattr-reply.png["MDS_GETATTR Reply Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The mds-getattr-reply.png diagram resembles this text art:
+
+ MDS_GETATTR:
+ --reply------------------------------------------------
+ | ptlrpc_body | mdt_body | MDS_MD | ACL | lustre_capa |
+ -------------------------------------------------------
+ | lustre_capa |
+ ---------------
+//////////////////////////////////////////////////////////////////////
+
It will also include the security capability (if appropriate). The
reply also holds the same fid, and in this case the 'mdt_body' has
several additional fields filled in. These include the mtime, atime,
The ost-connect-request.png diagram resembles this text art:
OST_CONNECT:
- --request--------------------------------------------
- | ptlrpc_body | obd_uuid | obd_uuid | lustre_handle |
- -----------------------------------------------------
+ --request--------------------------------------------------
+ | ptlrpc_body | target_uuid | client_uuid | lustre_handle |
+ -----------------------------------------------------------
| obd_connect_data |
---------------------
//////////////////////////////////////////////////////////////////////
+See <<ost-connect-rpc>>.
+
As with the connect operations for the MGS and MDTs, the connect
-message from the client includes a UUID to uniquely identify this
-connection, and subsequent messages to the lock manager on the server
-will refer to that UUID. The connection data from the client also
+message from the client includes a 'lustre_handle' to uniquely
+identify this connection. The connection data from the client also
proposes the set of <<connect-flags,connection flags>> appropriate to
connecting to an OST. The following are the flags always included.
git://git.whamcloud.com / doc / protocol.git / blobdiff