^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[[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
or is evicted then it must re-connect as a new client, with a new
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