RPC 38: MDS CONNECT - Client connection to an MDS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [[mds-connect-rpc]] The general behavior of MDS_CONNECT RPCs closely resembles that of OST_CONNECT RPCs (See <>). 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-request.png diagram resembles this text art: MDS_CONNECT: --request-------------------------------------------------- | ptlrpc_body | target_uuid | client_uuid | lustre_handle | ----------------------------------------------------------- | obd_connect_data | --------------------- ////////////////////////////////////////////////////////////////////// 'ptlrpc_body':: RPC descriptor. See <>. In a connect message the 'ptlrpc_body' field 'pb_handle', which is a <>, is 0. That 'lustre_handle' is distinct from the one mentioned below. 'target_uuid':: A string identifying the target. See <>. 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 <>. The target sets the 'exp_client_uuid' field of its 'export' structure to this value. 'lustre_handle':: See <>. 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 <>. 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>. The 'ocd_version' field contains the version of Lustre running on the client. Other fields in the 'obd_connect_data' structures are zero. .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 <>. 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 <>. 'obd_connect_data':: See <>.