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
   9 | ptlrpc_body | tgt_uuid | client_uuid | lustre_handle | obd_connect_data |
  10 |
  11 | reply
  12 | ptlrpc_body | obd_connect_data |
  13 |====
  14
  15 N.B. This is nearly identical to the explanation for OST_CONNECT and
  16 for MGS_CONNECT.  We may want to simplify and/or unify the discussion
  17 and only call out how this one differs from a generic CONNECT
  18 operation.
  19
  20 When a client initiates a connection to a specific target on an MDS,
  21 it does so by sending an 'obd_connect_client' message and awaiting the
  22 reply from the MDS of an 'obd_connect_server' message. From a previous
  23 interaction with the MGS the client knows the UUID of the target MDT,
  24 and must fill that value into the 'tgt_uuid' buffer of the request.
  25
  26 The 'client_uuid' buffer holds the randomly-generated 128-bit UUID of
  27 the client.  The 'client_uuid' is unique for each mount of the client.
  28 Even if the same client mounts the same filesystem multiple times it
  29 will generate a new 'client_uuid' value for each mount.
  30
  31 The 'lustre_handle' buffer contains the cookie for this connection,
  32 and is zero for a new mount.  If the client is reconnecting to a
  33 server after a loss of communication, the 'lustre_handle' contains
  34 the connection cookie previously assigned by the server and returned
  35 to the client in the reply.  This allows the server to determine if
  36 the client connection matches any previous connection from this client.
  37
  38 The 'ocd_connect_flags' buffer is initialized to the set of features
  39 that the client supports for metadata targets.  For Lustre 2.7 clients
  40 these features are OBD_CONNECT_IBITS, OBD_CONNECT_NODEVOH,
  41 OBD_CONNECT_ATTRFID, OBD_CONNECT_VERSION, OBD_CONNECT_BRW_SIZE,
  42 OBD_CONNECT_CANCELSET, OBD_CONNECT_FID, OBD_CONNECT_AT, OBD_CONNECT_LOV_V3,
  43 OBD_CONNECT_VBR, OBD_CONNECT_FULL20, OBD_CONNECT_64BITHASH,
  44 OBD_CONNECT_EINPROGRESS, OBD_CONNECT_JOBSTATS, OBD_CONNECT_LVB_TYPE,
  45 OBD_CONNECT_LAYOUTLOCK, OBD_CONNECT_PINGLESS, OBD_CONNECT_MAX_EASIZE,
  46 OBD_CONNECT_FLOCK_DEAD, OBD_CONNECT_DISP_STRIPE, OBD_CONNECT_LFSCK, and
  47 OBD_CONNECT_OPEN_BY_FID, as described in <<obd-connect-flags>>.
  48
  49 The 'ocd_brw_size' field is set to the largest size in bytes that the
  50 client can use for bulk transfers. The 'ocd_ibits_known' field is set to
  51 the supported set of IBITS locks, as of Lustre 2.7 these are
  52 MDS_INODELOCK_LOOKUP, MDS_INODELOCK_UPDATE, MDS_INODELOCK_OPEN,
  53 MDS_INODELOCK_LAYOUT, MDS_INODELOCK_PERM, and MDS_INODELOCK_XATTR,
  54 as described in <<mds-inode-bits-locks>>.
  55
  56 The 'ocd_version' field contains the version of Lustre
  57 running on the client. Other fields in the 'obd_connect_data'
  58 structures are zero.
  59
  60 Once the server receives the 'obd_connect_client' message on behalf of
  61 the given target it replies with an 'obd_connect_server' message. In
  62 the reply message the server sets the 'pb_handle' to uniquely
  63 identify this connection for subsequent communication. The client notes
  64 that handle in its import for the given target.  The reply also returns
  65 the 'obd_connect_data' as interpreted by the MDS.  Any features that
  66 the MDS does not support are masked out of 'ocd_feature_flags'.  Supported
  67 features that have assigned fields are filled in by the MDS.
  68
  69 fixme: Are there circumstances that could lead to the 'status'
  70 value in the reply being non-zero? What would lead to that and what
  71 error values would result?
  72 ans: yes, at least the standard errors
  73
  74 The target maintains the last committed transaction for a client in
  75 its export for that client. If this is the first connection, then that
  76 last transaction value would just be zero. If there were previous
  77 transactions for the client, then the transaction number for the last
  78 such committed transaction is put in the <<struct-ptlrpc-body>>
  79 'pb_last_committed' field.
  80
  81 In a connection request the operation is not file system modifying, so
  82 the 'pb_transno' value will be zero in the reply as well.
  83
  84 fixme: there is still some work to be done about how the fields are
  85 managed.