mds_connect.txt

   1 RPC 38: MDS CONNECT - Client connection to an MDS
   2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   3 [[mds-connect-rpc]]
   4
   5 .MDS_CONNECT Generic Packet Structure
   6 image::mds-connect-generic.png["MDS_CONNECT Generic Packet Structure",height=100]
   7
   8 //////////////////////////////////////////////////////////////////////
   9 The mds-connect-generic.png diagram resembles this text art:
  10
  11        MDS_CONNECT:
  12       --request--------------------------------------------
  13       | ptlrpc_body | obd_uuid | obd_uuid | lustre_handle |
  14       -----------------------------------------------------
  15       |  obd_connect_data |
  16       ---------------------
  17       --reply---------------------------
  18       | ptlrpc_body | obd_connect_data |
  19       ----------------------------------
  20 //////////////////////////////////////////////////////////////////////
  21
  22 'ptlrpc_body'::
  23 RPC descriptor.
  24
  25 'obd_uuid'::
  26 UUIDs of the target (first) and client (second) entities. See
  27 <<struct-obd-uuid>>.
  28
  29 'lustre_handle'::
  30 See <<struct-lustre-handle>>.
  31
  32 'obd_connect_data'::
  33 See <<struct-obd-connect-data>>.
  34
  35 The 'ocd_connect_flags' buffer is initialized to the set of features
  36 that the client supports for metadata targets.  For Lustre 2.7 clients
  37 these features are OBD_CONNECT_IBITS, OBD_CONNECT_NODEVOH,
  38 OBD_CONNECT_ATTRFID, OBD_CONNECT_VERSION, OBD_CONNECT_BRW_SIZE,
  39 OBD_CONNECT_CANCELSET, OBD_CONNECT_FID, OBD_CONNECT_AT, OBD_CONNECT_LOV_V3,
  40 OBD_CONNECT_VBR, OBD_CONNECT_FULL20, OBD_CONNECT_64BITHASH,
  41 OBD_CONNECT_EINPROGRESS, OBD_CONNECT_JOBSTATS, OBD_CONNECT_LVB_TYPE,
  42 OBD_CONNECT_LAYOUTLOCK, OBD_CONNECT_PINGLESS, OBD_CONNECT_MAX_EASIZE,
  43 OBD_CONNECT_FLOCK_DEAD, OBD_CONNECT_DISP_STRIPE, OBD_CONNECT_LFSCK, and
  44 OBD_CONNECT_OPEN_BY_FID, as described in <<obd-connect-flags>>.
  45
  46 The 'ocd_brw_size' field is set to the largest size in bytes that the
  47 client can use for bulk transfers. The 'ocd_ibits_known' field is set to
  48 the supported set of IBITS locks, as of Lustre 2.7 these are
  49 MDS_INODELOCK_LOOKUP, MDS_INODELOCK_UPDATE, MDS_INODELOCK_OPEN,
  50 MDS_INODELOCK_LAYOUT, MDS_INODELOCK_PERM, and MDS_INODELOCK_XATTR,
  51 as described in <<mds-inode-bits-locks>>.
  52
  53 The 'ocd_version' field contains the version of Lustre
  54 running on the client. Other fields in the 'obd_connect_data'
  55 structures are zero.
  56
  57 Once the server receives the 'obd_connect_client' message on behalf of
  58 the given target it replies with an 'obd_connect_server' message. In
  59 the reply message the server sets the 'pb_handle' to uniquely
  60 identify this connection for subsequent communication. The client notes
  61 that handle in its import for the given target.  The reply also returns
  62 the 'obd_connect_data' as interpreted by the MDS.  Any features that
  63 the MDS does not support are masked out of 'ocd_feature_flags'.  Supported
  64 features that have assigned fields are filled in by the MDS.
  65
  66 fixme: Are there circumstances that could lead to the 'status'
  67 value in the reply being non-zero? What would lead to that and what
  68 error values would result?
  69 ans: yes, at least the standard errors
  70
  71 The target maintains the last committed transaction for a client in
  72 its export for that client. If this is the first connection, then that
  73 last transaction value would just be zero. If there were previous
  74 transactions for the client, then the transaction number for the last
  75 such committed transaction is put in the <<struct-ptlrpc-body>>
  76 'pb_last_committed' field.
  77
  78 In a connection request the operation is not file system modifying, so
  79 the 'pb_transno' value will be zero in the reply as well.
  80
  81 fixme: there is still some work to be done about how the fields are
  82 managed.