X-Git-Url: https://git.whamcloud.com/?p=doc%2Fprotocol.git;a=blobdiff_plain;f=lustre_operations.txt;h=37e29cd21c56df8a5546ddb7e7024184d823bd42;hp=c8c3ab4128d836cce65b2e3e4a0acbbc3384bc32;hb=907058386e795d992ab307dda9d517a2a86fac8d;hpb=f7539c5d000a6cce00dd20959e071892011561dc diff --git a/lustre_operations.txt b/lustre_operations.txt index c8c3ab4..37e29cd 100644 --- a/lustre_operations.txt +++ b/lustre_operations.txt @@ -3,10 +3,10 @@ Lustre Operations [[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 <> and <> for how the client is given confirmation that a @@ -16,6 +16,7 @@ include::ost_setattr.txt[] Command 8: OST CONNECT - Client connection to an OST ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[[ost-connect-rpc]] .OST_CONNECT (8) [options="header"] @@ -34,7 +35,7 @@ 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 +considers appropriate. Other fields in the descriptor and 'obd_connect_data' structures are zero, as is the 'lustre_handle' element. @@ -50,7 +51,7 @@ 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 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. @@ -62,6 +63,7 @@ managed. Command 9: OST DISCONNECT - Disconnect client from an OST ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[[ost-disconnect-rpc]] .OST_DISCONNECT (9) [options="header"] @@ -71,12 +73,15 @@ Command 9: OST DISCONNECT - Disconnect client from an OST |==== 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"] @@ -90,6 +95,7 @@ include::mds_reint.txt[] Command 38: MDS CONNECT - Client connection to an MDS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[[mds-connect-rpc]] .MDS_CONNECT (38) [options="header"] @@ -100,7 +106,7 @@ Command 38: MDS CONNECT - Client connection to an MDS 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, @@ -113,7 +119,7 @@ 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 +considers appropriate. Other fields in the descriptor and 'obd_connect_data' structures are zero, as is the 'lustre_handle' element. @@ -129,7 +135,7 @@ 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 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. @@ -141,6 +147,7 @@ managed. Command 39: MDS DISCONNECT - Disconnect client from an MDS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[[mds-disconnect-rpc]] .MDS_DISCONNECT (39) [options="header"] @@ -150,10 +157,11 @@ Command 39: MDS DISCONNECT - Disconnect client from an MDS |==== 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. @@ -172,22 +180,7 @@ target is being asked about. 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[] @@ -199,8 +192,11 @@ include::ldlm_bl_callback.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"] @@ -225,7 +221,7 @@ 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 +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 @@ -240,7 +236,7 @@ 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 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. @@ -249,6 +245,7 @@ the 'pb_transno' value will be zero in the reply as well. Command 251: MGS DISCONNECT - Disconnect client from an MGS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[[mgs-disconnect-rpc]] .MGS_DISCONNECT (251) [options="header"] @@ -262,10 +259,11 @@ MGS_DISCONNECT. It will take a more careful code review to verify that 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"] @@ -276,6 +274,7 @@ Command 256: MGS CONFIG READ - Read MGS configuration info Command 501: LLOG ORIGIN HANDLE CREATE - Create llog handle ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[[llog-origin-handle-create-rpc]] .LLOG_ORIGIN_HANDLE_CREATE (510) [options="header"] @@ -286,6 +285,7 @@ Command 501: LLOG ORIGIN HANDLE CREATE - Create llog handle 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"] @@ -296,6 +296,7 @@ Command 502: LLOG ORIGIN HANDLE NEXT BLOCK - Read the next block Command 503: LLOG ORIGIN HANDLE READ HEADER - Read handle header ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +[[llog-origin-handle-read-header-rpc]] .LLOG_ORIGIN_HANDLE_READ_HEADER (503) [options="header"] @@ -304,4 +305,3 @@ Command 503: LLOG ORIGIN HANDLE READ HEADER - Read handle header | llogd_body_only | llog_log_hdr_only |==== -LLOG_ORIGIN_HANDLE_NEXT_BLOCK