^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[[struct-ptlrpc-body]]
-Every Lustre message starts with a header (See <<struct-lustre-msg>>)
-describing a few generic details about the RPC, the most important of
-which is the number and sizes of additional "buffers" that will
-follow. The buffers just organize subsections of the RPC, and each
-comprises a set of fields. The fields of a buffer are presented here
-as 'struct' definitions because that is how they are actually
-organized, and it provides a convenient way to refer to groups of
-fields that appear together in many different RPCs. The first buffer
-in every RPC is given by the 'ptlrpc_body' structure, also known as
-the RPC descriptor. This descriptor identifies the type of the RPC via
-a Lustre operation code. The value of that 'opcode', as well as
-whether it is an RPC 'request' or 'reply', determines what other
-buffers will be in the message following the descriptor.
+Every Lustre message starts with a header (not shown - see
+<<struct-lustre-msg>>) describing a few generic details about the RPC,
+the most important of which is the number and sizes of additional
+"buffers" that will follow. The buffers just organize subsections of
+the RPC, and each comprises a set of fields. The fields of given a buffer
+are presented together as 'struct' definitions in order to show how they
+are organized, and it provides a convenient way to refer to
+groups of fields that appear together in many different RPCs. The
+first buffer in every RPC is given by the 'ptlrpc_body' structure,
+also known as the RPC descriptor. This descriptor identifies the type
+of the RPC via a Lustre operation code. The value of that 'opcode', as
+well as whether it is an RPC 'request' or 'reply', determines what
+other buffers will be in the message following the descriptor.
[source,c]
----
connection request 'pb_handle' is set to a new 'lustre_handle' that
uniquely identifies the target (indeed, it uniquely identifies the
'export', since each client gets a unique 'lustre_handle' for a given
-target). Subsequent request messages sent this client to this target
+target). Subsequent request messages sent from this client to this target
will use that 'lustre_handle' (the 'pb_handle' field will be set to
that value) to to gain access to their shared state. In subsequent RPC
-reply messages (after teh *_CONNECT reply) the 'pb_handle' field is
+reply messages (after the *_CONNECT reply) the 'pb_handle' field is
0. The 'lustre_handle' is persistent across client reconnects to the
-same instance of the server, but if the client unmounts the filesystem
+same instance of the server, but if the client unmounts the file system
or is evicted then it must re-connect as a new client, with a new
'lustre_handle'.
| UPDATE_OBJ | 1000
|====
-The 'pb_status' field was already mentioned above in conjuction with
+The 'pb_status' field was already mentioned above in conjunction with
the 'pb_type' field in replies. In a request message 'pb_status' is
set to the 'pid' of the process making the request. In a reply
message, a zero indicates that the service successfully initiated the
server-assigned transaction number for the client request. See
<<transno>>. Upon receipt of the reply, the client copies this
transaction number from 'pb_transno' of the reply to 'pb_transno' of
-the saved request. If 'pb_transno' is larger than 'pb_last_commited'
+the saved request. If 'pb_transno' is larger than 'pb_last_committed'
(above) then the request has been processed at the target but is not
yet committed to stable storage. The client must save the request for
later resend to the server in case the target fails before the
and is ready to finish recovery.
The 'pb_op_flags' values are specific to a particular 'pb_opc', but
-are currently only used by the *_CONNECT RPCs.The 'pb_op_flags' value
+are currently only used by the *_CONNECT RPCs. The 'pb_op_flags' value
for connect operations governs the client connection status state
machine.
git://git.whamcloud.com / doc / protocol.git / blobdiff