[[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
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"]
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.
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.
+include::mds_statfs.txt[]
include::mds_getxattr.txt[]
include::ldlm_cp_callback.txt[]
+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