[[lustre-operations]]
Lustre operations are denoted by the 'pb_opc' op-code field of the
-message preamble. Each operation is implemented as a pair of messages,
+RPC descriptor. Each operation is implemented as a pair of messages,
with the 'pb_type' field set to PTLRPC_MSG_REQUEST for requests
initiating the operation, and PTLRPC_MSG_REPLY for replies. Note that
-as a general matter, the receipt by a client of the rply message only
+as a general matter, the receipt by a client of the reply message only
assures the client hat the server has initiated the action, if
any. See the discussion on <<transno,transaction numbers>>
and <<recovery>> for how the client is given confirmation that a
request has been completed.
+include::ost_setattr.txt[]
+
Command 8: OST CONNECT - Client connection to an OST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[ost-connect-rpc]]
.OST_CONNECT (8)
[options="header"]
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 preamble and
+considers appropriate. Other fields in the descriptor and
'obd_connect_data' structures are zero, as is the 'lustre_handle'
element.
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 transactiion value would just be zero. If there were previous
+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.
Command 9: OST DISCONNECT - Disconnect client from an OST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[ost-disconnect-rpc]]
.OST_DISCONNECT (9)
[options="header"]
|====
The information exchanged in a DISCONNECT message is that normally
-conveyed in the mesage preamble.
+conveyed in the RPC descriptor.
+
+include::ost_punch.txt[]
+
+include::ost_statfs.txt[]
Command 33: MDS GETATTR - Get MDS Attributes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[mds-getattr-rpc]]
.MDS_GETATTR (33)
[options="header"]
|====
+include::mds_reint.txt[]
Command 38: MDS CONNECT - Client connection to an MDS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[mds-connect-rpc]]
.MDS_CONNECT (38)
[options="header"]
N.B. This is nearly identical to the explanation for OST_CONNECT and
for MGS_CONNECT. We may want to simplify and/or unify the discussion
-and only call out how this one differees from a generic CONNECT
+and only call out how this one differs from a generic CONNECT
operation.
When a client initiates a connection to a specific target on an MDS,
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 preamble and
+considers appropriate. Other fields in the descriptor and
'obd_connect_data' structures are zero, as is the 'lustre_handle'
element.
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 transactiion value would just be zero. If there were previous
+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.
Command 39: MDS DISCONNECT - Disconnect client from an MDS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[mds-disconnect-rpc]]
.MDS_DISCONNECT (39)
[options="header"]
|====
The information exchanged in a DISCONNECT message is that normally
-conveyed in the mesage preamble.
+conveyed in the RPC descriptor.
Command 40: MDS GETSTATUS - get the status from a target
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[mds-getstatus-rpc]]
The MDS_GETSTATUS command targets a specific MDT. If there are several,
the client will need to send a separate message for each.
-.MDS_GETSTATUS (41)
+.MDS_GETSTATUS (40)
[options="header"]
|====
| request | reply
In the reply there is additional information about the MDT's
capabilities.
-Command 41: MDS STATFS - get statfs data from the server
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.MDS_STATFS (41)
-[options="header"]
-|====
-| request | reply
-| empty | obd_statfs_server
-|====
-
-The 'empty' request message is one that only has the 'ptlrpc_body'
-data encoded. The fields have thier generic values for a request from
-this client, with 'pb_opc' being set to MDS_STATFS (41).
-
-In the reply there is, in addition to the 'ptlrpc_body', data relevant
-to a 'statfs' system call.
-
-Command 101: LDLM ENQUEUE - Enqueue a lock request
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.LDLM_ENQUEUE (101)
-[options="header"]
-|====
-| request | reply
-| ldlm_enqueue_client | ldlm_enqueue_lvb_server
-|====
-
-In order to access data on disk at a target the client needs to
-establish a lock (either concurrent for reads or exclusive for
-writes). The client sends the 'ldlm_enqueue_client' message to the
-server holding the target, and the server will reply with an
-'ldlm_enqueue_server' message. (N.B. It actuallity it is an
-'ldlm_enqueue_lvb_server' message with the length of the 'struct
-ost_lvb' portion set to zero, which ammounts to the same thing).
-
-The target UUID is just "MGS", and the client UUID is set to the
-32byte string it gets from ... where?
+include::mds_statfs.txt[]
-The 'struct lustre_handle' (the fourth buffer in the message) has its
-cookie set to .. what? It is set, but where does it come from?
+include::mds_getxattr.txt[]
-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 preamble and
-'obd_connect_data' structures are zero.
+include::ldlm_enqueue.txt[]
-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.
+include::ldlm_cancel.txt[]
-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?
+include::ldlm_bl_callback.txt[]
-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 transactiion 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.
+include::ldlm_cp_callback.txt[]
-In a connection request the operation is not file system modifying, so
-the 'pb_transno' value will be zero in the reply as well.
+include::ldlm_gl_callback.txt[]
Command 250: MGS CONNECT - Client connection to an MGS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[mgs-connect-rpc]]
.MGS_CONNECT (250)
[options="header"]
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 preamble and
+considers appropriate. Other fields in the descriptor and
'obd_connect_data' structures are zero.
Once the server receives the 'obd_connect_client' message on behalf of
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 transactiion value would just be zero. If there were previous
+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.
Command 251: MGS DISCONNECT - Disconnect client from an MGS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[mgs-disconnect-rpc]]
.MGS_DISCONNECT (251)
[options="header"]
it also has 'empty' messages gong back and forth.
The information exchanged in a DISCONNECT message is that normally
-conveyed in the mesage preamble.
+conveyed in the RPC descriptor.
Command 256: MGS CONFIG READ - Read MGS configuration info
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[mgs-config-read-rpc]]
.MGS_CONFIG_READ (256)
[options="header"]
Command 501: LLOG ORIGIN HANDLE CREATE - Create llog handle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[llog-origin-handle-create-rpc]]
.LLOG_ORIGIN_HANDLE_CREATE (510)
[options="header"]
Command 502: LLOG ORIGIN HANDLE NEXT BLOCK - Read the next block
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[llog-origin-handle-next-block-rpc]]
.LLOG_ORIGIN_HANDLE_NEXT_BLOCK (502)
[options="header"]
Command 503: LLOG ORIGIN HANDLE READ HEADER - Read handle header
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+[[llog-origin-handle-read-header-rpc]]
.LLOG_ORIGIN_HANDLE_READ_HEADER (503)
[options="header"]
| llogd_body_only | llog_log_hdr_only
|====
-LLOG_ORIGIN_HANDLE_NEXT_BLOCK
git://git.whamcloud.com / doc / protocol.git / blobdiff