~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[[ost-connect-rpc]]
-.OST_CONNECT (8)
-[options="header"]
-|====
-| request | reply
-| obd_connect_client | obd_connect_server
-|====
-
When a client initiates a connection to a specific target on an OSS,
-it does so by sending an 'obd_connect_client' message and awaiting the
-reply from the OSS of an 'obd_connect_server' message. From a previous
-interaction with the MGS the client knows the UUID of the target OST,
-and can fill that value into the 'obd_connect_client' message.
-
-The 'ocd_connect_flags' field is set to (fixme: what?) reflecting the
-capabilities appropriate to the client. The 'ocd_brw_size' is set to the
-largest value for the size of an RPC that the client can handle. The
-'ocd_ibits_known' and 'ocd_checksum_types' values are set to what the client
-considers appropriate. Other fields in the descriptor and
-'obd_connect_data' structures are zero, as is the 'lustre_handle'
-element.
-
-Once the server receives the 'obd_connect_client' message on behalf of
-the given target it replies with an 'obd_connect_server' message. In
-that message the server sends the 'pb__handle' to uniquely
-identify the connection for subsequent communication. The client notes
-that handle in its import for the given target.
-
-fixme: Are there circumstances that could lead to the 'status'
-value in the reply being non-zero? What would lead to that and what
-error values would result?
-
-The target maintains the last committed transaction for a client in
-its export for that client. If this is the first connection, then that
-last transaction value would just be zero. If there were previous
-transactions for the client, then the transaction number for the last
-such committed transaction is put in the 'pb_last_committed' field.
-
-In a connection request the operation is not file system modifying, so
-the 'pb_transno' value will be zero in the reply as well.
-
-fixme: there is still some work to be done about how the fields are
-managed.
+it does so via an OST_CONNECT RPC ('pb_opc' = 8).
+
+.OST_CONNECT Request Packet Structure
+image::ost-connect-request.png["OST_CONNECT Request Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The ost-connect-request.png diagram resembles this text art:
+
+ OST_CONNECT:
+ --request--------------------------------------------------
+ | ptlrpc_body | target_uuid | client_uuid | lustre_handle |
+ -----------------------------------------------------------
+ | obd_connect_data |
+ --------------------
+//////////////////////////////////////////////////////////////////////
+
+'ptlrpc_body'::
+RPC descriptor. See <<struct-ptlrpc-body>>. In a connect message the
+'ptlrpc_body' field 'pb_handle', which is a <<struct-lustre-handle>>,
+is 0. That 'lustre_handle' is distinct from the one mentioned
+below.
+
+'target_uuid'::
+A string identifying the target. See <<struct-obd-uuid>>. The client
+learns the UUID strings for the targets via an interaction with the
+MGS.
+
+'client_uuid'::
+A string with the client's own UUID. This is also an
+<<struct-obd-uuid>>. The target sets the 'exp_client_uuid' field of
+its 'export' structure to this value.
+
+'lustre_handle'::
+See <<struct-lustre-handle>>. This 'lustre_handle' is distinct from
+the 'pb_handle' field in the 'ptlrpc_body'. This 'lustre_handle'
+provides a unique 'cookie' to identify this client for this connection
+attempt. After a disconnect, a subsequent connect RPC will have a
+different value. The target preserves this cookie in the 'exp_handle'
+field of its 'obd_export' structure for this client. In that way it
+can distinguish between a resent connection request and an entirely
+new connection request.
+
+'obd_connect_data'::
+See <<struct-obd-connect-data>>.
+
+.OST_CONNECT Reply Packet Structure
+image::ost-connect-reply.png["OST_CONNECT Reply Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The ost-connect-reply.png diagram resembles this text art:
+
+ OST_CONNECT:
+ --reply---------------------------
+ | ptlrpc_body | obd_connect_data |
+ ----------------------------------
+//////////////////////////////////////////////////////////////////////
+
+'ptlrpc_body'::
+RPC descriptor. See <<struct-ptlrpc-body>>. The 'pb_handle' field has
+the value, C~t~, uniquely identifying that target. The value C~t~ is
+preserved in the 'imp_remote_handle' field of the client's import
+structure for this target. See <<struct-obd-import>>.
+'obd_connect_data'::
+See <<struct-obd-connect-data>>.
git://git.whamcloud.com / doc / protocol.git / blobdiff