~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[[mds-connect-rpc]]
-.MDS_CONNECT Generic Packet Structure
-image::mds-connect-generic.png["MDS_CONNECT Generic Packet Structure",height=100]
+The general behavior of MDS_CONNECT RPCs closely resembles that of
+OST_CONNECT RPCs (See <<ost-connect-rpc>>). The actual RPC's 'pb_opc'
+value will be different as are the names of the targets and the
+specific values in the 'obd_connect_data' structure.
+
+.MDS_CONNECT Request Packet Structure
+image::mds-connect-request.png["MDS_CONNECT Request Packet Structure",height=50]
//////////////////////////////////////////////////////////////////////
-The mds-connect-generic.png diagram resembles this text art:
+The mds-connect-request.png diagram resembles this text art:
MDS_CONNECT:
- --request--------------------------------------------
- | ptlrpc_body | obd_uuid | obd_uuid | lustre_handle |
- -----------------------------------------------------
- | obd_connect_data |
+ --request--------------------------------------------------
+ | ptlrpc_body | target_uuid | client_uuid | lustre_handle |
+ -----------------------------------------------------------
+ | obd_connect_data |
---------------------
- --reply---------------------------
- | ptlrpc_body | obd_connect_data |
- ----------------------------------
//////////////////////////////////////////////////////////////////////
'ptlrpc_body'::
-RPC descriptor.
+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.
-'obd_uuid'::
-UUIDs of the target (first) and client (second) entities. See
-<<struct-obd-uuid>>.
+'client_uuid'::
+A string with the client's own UUID. This is also a
+<<struct-obd-uuid>>. The target sets the 'exp_client_uuid' field of
+its 'eport' structure to this value.
'lustre_handle'::
-See <<struct-lustre-handle>>.
+See <<struct-lustre-handle>>. This 'lustre_handle' is distinct from
+the 'pb_handle' field in the 'ptlrpc_body'. This 'lustre_handle'
+provied 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>>.
-The 'ocd_connect_flags' buffer is initialized to the set of features
-that the client supports for metadata targets. For Lustre 2.7 clients
-these features are OBD_CONNECT_IBITS, OBD_CONNECT_NODEVOH,
-OBD_CONNECT_ATTRFID, OBD_CONNECT_VERSION, OBD_CONNECT_BRW_SIZE,
-OBD_CONNECT_CANCELSET, OBD_CONNECT_FID, OBD_CONNECT_AT, OBD_CONNECT_LOV_V3,
-OBD_CONNECT_VBR, OBD_CONNECT_FULL20, OBD_CONNECT_64BITHASH,
-OBD_CONNECT_EINPROGRESS, OBD_CONNECT_JOBSTATS, OBD_CONNECT_LVB_TYPE,
-OBD_CONNECT_LAYOUTLOCK, OBD_CONNECT_PINGLESS, OBD_CONNECT_MAX_EASIZE,
-OBD_CONNECT_FLOCK_DEAD, OBD_CONNECT_DISP_STRIPE, OBD_CONNECT_LFSCK, and
-OBD_CONNECT_OPEN_BY_FID, as described in <<obd-connect-flags>>.
-
The 'ocd_brw_size' field is set to the largest size in bytes that the
-client can use for bulk transfers. The 'ocd_ibits_known' field is set to
-the supported set of IBITS locks, as of Lustre 2.7 these are
-MDS_INODELOCK_LOOKUP, MDS_INODELOCK_UPDATE, MDS_INODELOCK_OPEN,
-MDS_INODELOCK_LAYOUT, MDS_INODELOCK_PERM, and MDS_INODELOCK_XATTR,
-as described in <<mds-inode-bits-locks>>.
+client can use for bulk transfers.
+
+The 'ocd_ibits_known' field is set to the supported set of IBITS
+locks. As of Lustre 2.7 these are MDS_INODELOCK_LOOKUP,
+MDS_INODELOCK_UPDATE, MDS_INODELOCK_OPEN, MDS_INODELOCK_LAYOUT,
+MDS_INODELOCK_PERM, and MDS_INODELOCK_XATTR>.
The 'ocd_version' field contains the version of Lustre
running on the client. Other fields in the 'obd_connect_data'
structures are zero.
-Once the server receives the 'obd_connect_client' message on behalf of
-the given target it replies with an 'obd_connect_server' message. In
-the reply message the server sets the 'pb_handle' to uniquely
-identify this connection for subsequent communication. The client notes
-that handle in its import for the given target. The reply also returns
-the 'obd_connect_data' as interpreted by the MDS. Any features that
-the MDS does not support are masked out of 'ocd_feature_flags'. Supported
-features that have assigned fields are filled in by the MDS.
-
-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?
-ans: yes, at least the standard errors
-
-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 <<struct-ptlrpc-body>>
-'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.
+.MDS_CONNECT Reply Packet Structure
+image::mds-connect-reply.png["MDS_CONNECT Reply Packet Structure",height=50]
+
+//////////////////////////////////////////////////////////////////////
+The mds-connect-reply.png diagram resembles this text art:
+
+ MDS_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