RPC 8: OST CONNECT - Client connection to an OST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[[ost-connect-rpc]]

.OST_CONNECT (8)
[options="header"]
|====
| request            | reply
| obd_connect_client | obd_connect_server
|====

When a client initiates a connection to a specific target on an OSS,
it does so by sending an 'obd_connect_client' message and awaiting the
reply from the OSS of an 'obd_connect_server' message. From a previous
interaction with the MGS the client knows the UUID of the target OST,
and can fill that value into the 'obd_connect_client' message.

The 'ocd_connect_flags' field is set to (fixme: what?) reflecting the
capabilities appropriate to the client. The 'ocd_brw_size' is set to the
largest value for the size of an RPC that the client can handle. The
'ocd_ibits_known' and 'ocd_checksum_types' values are set to what the client
considers appropriate. Other fields in the descriptor and
'obd_connect_data' structures are zero, as is the 'lustre_handle'
element.

Once the server receives the 'obd_connect_client' message on behalf of
the given target it replies with an 'obd_connect_server' message. In
that message the server sends the 'pb__handle' to uniquely
identify the connection for subsequent communication. The client notes
that handle in its import for the given target.

fixme: Are there circumstances that could lead to the 'status'
value in the reply being non-zero? What would lead to that and what
error values would result?

The target maintains the last committed transaction for a client in
its export for that client. If this is the first connection, then that
last transaction value would just be zero. If there were previous
transactions for the client, then the transaction number for the last
such committed transaction is put in the 'pb_last_committed' field.

In a connection request the operation does not modify the filesystem,
so the 'pb_transno' value will be zero in the reply as well.

fixme: there is still some work to be done about how the fields are
managed.