mds_connect.txt

   1 RPC 38: MDS CONNECT - Client connection to an MDS
   2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   3 [[mds-connect-rpc]]
   4
   5 .MDS_CONNECT (38)
   6 [options="header"]
   7 |====
   8 | request            | reply
   9 | obd_connect_client | obd_connect_server
  10 |====
  11
  12 N.B. This is nearly identical to the explanation for OST_CONNECT and
  13 for MGS_CONNECT.  We may want to simplify and/or unify the discussion
  14 and only call out how this one differs from a generic CONNECT
  15 operation.
  16
  17 When a client initiates a connection to a specific target on an MDS,
  18 it does so by sending an 'obd_connect_client' message and awaiting the
  19 reply from the MDS of an 'obd_connect_server' message. From a previous
  20 interaction with the MGS the client knows the UUID of the target MDT,
  21 and can fill that value into the 'obd_connect_client' message.
  22
  23 The 'ocd_connect_flags' field is set to (fixme: what?) reflecting the
  24 capabilities appropriate to the client. The 'ocd_brw_size' is set to the
  25 largest value for the size of an RPC that the client can handle. The
  26 'ocd_ibits_known' and 'ocd_checksum_types' values are set to what the client
  27 considers appropriate. Other fields in the descriptor and
  28 'obd_connect_data' structures are zero, as is the 'lustre_handle'
  29 element.
  30
  31 Once the server receives the 'obd_connect_client' message on behalf of
  32 the given target it replies with an 'obd_connect_server' message. In
  33 that message the server sends the 'pb__handle' to uniquely
  34 identify the connection for subsequent communication. The client notes
  35 that handle in its import for the given target.
  36
  37 fixme: Are there circumstances that could lead to the 'status'
  38 value in the reply being non-zero? What would lead to that and what
  39 error values would result?
  40
  41 The target maintains the last committed transaction for a client in
  42 its export for that client. If this is the first connection, then that
  43 last transaction value would just be zero. If there were previous
  44 transactions for the client, then the transaction number for the last
  45 such committed transaction is put in the 'pb_last_committed' field.
  46
  47 In a connection request the operation is not file system modifying, so
  48 the 'pb_transno' value will be zero in the reply as well.
  49
  50 fixme: there is still some work to be done about how the fields are
  51 managed.