mgs_connect.txt

   1 RPC 250: MGS CONNECT - Client connection to an MGS
   2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   3 [[mgs-connect-rpc]]
   4
   5 The general behavior of MGS_CONNECT RPCs closely resembles that of
   6 OST_CONNECT RPCs (See <<ost-connect-rpc>>) and MDS_CONNECT RPCs. The
   7 actual RPC's 'pb_opc' value will be different as are the names of the
   8 targets and the specific values in the 'obd_connect_data' structure.
   9
  10 .MGS_CONNECT Request Packet Structure
  11 image::mgs-connect-request.png["MGS_CONNECT Request Packet Structure",height=50]
  12
  13 //////////////////////////////////////////////////////////////////////
  14 The mgs-connect-request.png diagram resembles this text art:
  15
  16        MGS_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 'export' 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 provides 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_connect_flags' field reflects the capabilities appropriate to
  54 the client. The 'ocd_brw_size' is set to the largest value for the
  55 size of an RPC that the client can handle. The 'ocd_ibits_known' and
  56 'ocd_checksum_types' values are set to what the client considers
  57 appropriate. Other fields in the descriptor and 'obd_connect_data'
  58 structures are zero.
  59
  60 .MGS_CONNECT Reply Packet Structure
  61 image::mgs-connect-reply.png["MGS_CONNECT Reply Packet Structure",height=50]
  62
  63 //////////////////////////////////////////////////////////////////////
  64 The mgs-connect-reply.png diagram resembles this text art:
  65
  66        MGS_CONNECT:
  67       --reply---------------------------
  68       | ptlrpc_body | obd_connect_data |
  69       ----------------------------------
  70 //////////////////////////////////////////////////////////////////////
  71
  72 'ptlrpc_body'::
  73 See <<struct-ptlrpc-body>> for details about the RPC descriptor. In a
  74 connect message the 'ptlrpc_body' field 'pb_handle', which is a
  75 <<struct-lustre-handle>>, is 0. That 'lustre_handle' is distinct from
  76 the one mentioned below. In a reply, the 'pb_handle' field has the
  77 value, $C_t$, uniquely identifying that target. The value $C_t$ is
  78 preserved in the 'imp_remote_handle' field of the client's import
  79 structure for this target. See <<struct-obd-import>>.
  80
  81 'obd_connect_data'::
  82 See <<struct-obd-connect-data>>.