mds_connect.txt

   1 RPC 38: MDS CONNECT - Client connection to an MDS
   2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   3 [[mds-connect-rpc]]
   4
   5 The general behavior of MDS_CONNECT RPCs closely resembles that of
   6 OST_CONNECT RPCs (See <<ost-connect-rpc>>). The actual RPC's 'pb_opc'
   7 value will be different as are the names of the targets and the
   8 specific values in the 'obd_connect_data' structure.
   9
  10 .MDS_CONNECT Request Packet Structure
  11 image::mds-connect-request.png["MDS_CONNECT Request Packet Structure",height=50]
  12
  13 //////////////////////////////////////////////////////////////////////
  14 The mds-connect-request.png diagram resembles this text art:
  15
  16        MDS_CONNECT:
  17       --request--------------------------------------------------
  18       | ptlrpc_body | target_uuid | client_uuid | lustre_handle |
  19       -----------------------------------------------------------
  20       | obd_connect_data |
  21       ---------------------
  22 //////////////////////////////////////////////////////////////////////
  23
  24 'ptlrpc_body'::
  25 RPC descriptor. See <<struct-ptlrpc-body>>. In a connect message the
  26 'ptlrpc_body' field 'pb_handle', which is a <<struct-lustre-handle>>,
  27 is 0. That 'lustre_handle' is distinct from the one mentioned
  28 below.
  29
  30 'target_uuid'::
  31 A string identifying the target. See <<struct-obd-uuid>>. The client
  32 learns the UUID strings for the targets via an interaction with the
  33 MGS.
  34
  35 'client_uuid'::
  36 A string with the client's own UUID. This is also a
  37 <<struct-obd-uuid>>. The target sets the 'exp_client_uuid' field of
  38 its 'eport' structure to this value.
  39
  40 'lustre_handle'::
  41 See <<struct-lustre-handle>>. This 'lustre_handle' is distinct from
  42 the 'pb_handle' field in the 'ptlrpc_body'.  This 'lustre_handle'
  43 provied a unique 'cookie' to identify this client for this connection
  44 attempt. After a disconnect, a subsequent connect RPC will have a
  45 different value. The target preserves this cookie in the 'exp_handle'
  46 field of its 'obd_export' structure for this client. In that way it
  47 can distinguish between a resent connection request and an entirely
  48 new connection request.
  49
  50 'obd_connect_data'::
  51 See <<struct-obd-connect-data>>.
  52
  53 The 'ocd_brw_size' field is set to the largest size in bytes that the
  54 client can use for bulk transfers.
  55
  56 The 'ocd_ibits_known' field is set to the supported set of IBITS
  57 locks. As of Lustre 2.7 these are MDS_INODELOCK_LOOKUP,
  58 MDS_INODELOCK_UPDATE, MDS_INODELOCK_OPEN, MDS_INODELOCK_LAYOUT,
  59 MDS_INODELOCK_PERM, and MDS_INODELOCK_XATTR>.
  60
  61 The 'ocd_version' field contains the version of Lustre
  62 running on the client. Other fields in the 'obd_connect_data'
  63 structures are zero.
  64
  65 .MDS_CONNECT Reply Packet Structure
  66 image::mds-connect-reply.png["MDS_CONNECT Reply Packet Structure",height=50]
  67
  68 //////////////////////////////////////////////////////////////////////
  69 The mds-connect-reply.png diagram resembles this text art:
  70
  71        MDS_CONNECT:
  72       --reply---------------------------
  73       | ptlrpc_body | obd_connect_data |
  74       ----------------------------------
  75 //////////////////////////////////////////////////////////////////////
  76
  77 'ptlrpc_body'::
  78 RPC descriptor. See <<struct-ptlrpc-body>>. The 'pb_handle' field has
  79 the value, $C_t$, uniquely identifying that target. The value $C_t$ is
  80 preserved in the 'imp_remote_handle' field of the client's import
  81 structure for this target. See <<struct-obd-import>>.
  82
  83 'obd_connect_data'::
  84 See <<struct-obd-connect-data>>.