Whamcloud - gitweb
LUDOC-296 protocol: Reorganize the document ot be top-down
[doc/protocol.git] / basement / lustre_messages.txt
diff --git a/basement/lustre_messages.txt b/basement/lustre_messages.txt
new file mode 100644 (file)
index 0000000..89188f6
--- /dev/null
@@ -0,0 +1,369 @@
+Lustre Messages
+---------------
+[[lustre-messages]]
+
+A Lustre message is a sequence of bytes. The message begins with a
+<<lustre-message-header,Lustre Message Header>> and has between one
+and nine sub-sequences called "buffers". Each buffer has a structure
+(the size and meaning of the bytes) that corresponds to the 'struct'
+entities in the <<data-structs,Data Structures and Defines Section>>
+Section. The header gives the number of buffers in its 'lm_buffcount'
+field. The first buffer in any message is always the
+<<struct-ptlrpc-body,Lustre RPC Descriptor>>. The operation
+code ('pb_opc' field) and the message type ('pb_type' field: request
+or reply?) in the descriptor together specify the "format" of the
+message, where the format is the number and content of the remaining
+buffers. As a shorthand, it is useful to name each of these formats,
+and the following list gives all of the formats along with the number
+and content of the buffers for messages in that format. Note that
+while the combination of 'pb_opc' and 'pb_type' uniquely determines a
+message's format, the reverse is not true. A given format may be used
+in many different messages.
+
+N.B. As each of the following "message formats" is introduced in the
+context of describing "Lustre commands", the corresponding section
+here will be deleted. These brief entries just state the name of the
+format and its structures. That information is better included in the
+section on the command itself. -ACU
+
+The LLog Origin Handle Create Client
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'llog_origin_handle_create_client'
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc                    | pb_type
+| LLOG_ORIGIN_HANDLE_CREATE | PTL_RPC_MSG_REQUEST
+|====
+
+
+An 'llog_origin_handle_create_client' message format is used to
+ask for the creation of a log entry object.
+
+.format
+[options="header"]
+|====
+| structure    | meaning
+| ptlrpc_body  | RPC descriptor
+| llogd_body   | LLog description
+| string       | The name of the desired log
+|====
+
+Fixme: I don't actually see where the string gets set.
+
+The LLog Service (body-only) Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'llogd_body_only'
+^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc                    | pb_type
+| LLOG_ORIGIN_HANDLE_CREATE | PTL_RPC_MSG_REPLY
+|====
+
+
+An 'llogd_body_only' message replies with information about the log.
+
+.format
+[options="header"]
+|====
+| structure    | meaning
+| ptlrpc_body  | RPC descriptor
+| llogd_body   | LLog description
+|====
+
+
+The LLog Log (header-only) Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'llog_log_hdr_only'
+^^^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc                         | pb_type
+| LLOG_ORIGIN_HANDLE_READ_HEADER | PTL_RPC_MSG_REPLY
+|====
+
+
+An 'llog_log_hdr_only' message replies with header information from
+the log.
+
+.format
+[options="header"]
+|====
+| structure     | meaning
+| ptlrpc_body   | RPC descriptor
+| llog_log_hdr  | LLog log header info
+|====
+
+
+The LLog Return Next Block from Server
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'llog_origin_handle_next_block_server'
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc                        | pb_type
+| LLOG_ORIGIN_HANDLE_NEXT_BLOCK | PTL_RPC_MSG_REPLY
+|====
+
+
+An 'llog_origin_handle_next_block_server' message replies with the
+next block of data from the log.
+
+.format
+[options="header"]
+|====
+| structure     | meaning
+| ptlrpc_body   | RPC descriptor
+| llogd_body    | LLog description
+| eadata       | variable length field for extended attributes
+|====
+
+
+The MDS Getattr Server Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'mds_getattr_server'
+^^^^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc      | pb_type
+| MDS_GETATTR | PTL_RPC_MSG_REPLY
+|====
+
+An 'mds_getattr_server' message format is used to convey MDT data along
+with information about the Lustre capabilities of that MDT.
+
+.format
+[options="header"]
+|====
+| structure        | meaning
+| ptlrpc_body      | RPC descriptor
+| mdt_body        | Information about the MDT
+| MDT_MD          | OST stripe and index info
+| ACL             | ACLs for the fid
+| lustre_capa     | Security capa info for fid1
+| lustre_capa     | Security capa info for fid2
+|====
+
+An 'mdt_getattr_server' message concatenates three data elements into
+a single byte-stream. The three elements correspond to structures
+detailed in the <<data-structs,Data Structures and Defines Section>>.
+
+The MDT Capability Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'mdt_body_capa'
+^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc        | pb_type
+| MDS_GETSTATUS | PTL_RPC_MSG_REPLY
+| MDS_GETATTR   | PTL_RPC_MSG_REQUEST
+|====
+
+An 'mdt_body_capa' message format is used to convey MDT data along
+with information about the Lustre capabilities of that MDT.
+
+.format
+[options="header"]
+|====
+| structure        | meaning
+| ptlrpc_body      | RPC descriptor
+| mdt_body        | Information about the MDT
+| lustre_capa     | security capa info
+|====
+
+An 'mdt_body_capa' message concatenates three data elements into
+a single byte-stream. The three elements correspond to structures
+detailed in the <<data-structs,Data Structures and Defines Section>>.
+
+The MDT "Body Only" Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'mdt_body_only'
+^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc        | pb_type
+| MDS_GETSTATUS | PTL_RPC_MSG_REQUEST
+|====
+
+
+An 'mdt_body_only' message format is used to convey MDT data.
+
+.format
+[options="header"]
+|====
+| structure        | meaning
+| ptlrpc_body      | RPC descriptor
+| mdt_body        | Information about the MDT
+|====
+
+An 'mdt_body_only' message concatenates two data elements into
+a single byte-stream. The two elements correspond to structures
+detailed in the <<data-structs,Data Structures and Defines Section>>.
+
+The MGS Config Read Client Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'mgs_config_read_client'
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc          | pb_type
+| MGS_CONFIG_READ | PTL_RPC_MSG_REQUEST
+|====
+
+An 'mgs_config_read_client' message requests configuration data from
+the MGS.
+
+.format
+[options="header"]
+|====
+| structure        | meaning
+| ptlrpc_body      | RPC descriptor
+| mgs_config_body  | Information about the MGS supporting the request
+|====
+
+
+The MGS Config Read Server Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'mgs_config_read_server'
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc          | pb_type
+| MGS_CONFIG_READ | PTL_RPC_MSG_REPLY
+|====
+
+An 'mgs_config_read_server' message returns configuration data from
+the MGS.
+
+.format
+[options="header"]
+|====
+| structure        | meaning
+| ptlrpc_body      | RPC descriptor
+| mgs_config_body  | Information about the MGS supporting the request
+|====
+
+
+The OBD Connect Client Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'obd_connect_client'
+^^^^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc      | pb_type
+| MDS_CONNECT | PTL_RPC_MSG_REQUEST
+|====
+
+
+An 'obd_connect_client' message format is used to initiate the
+connection from one host to a target on another host. Clients will
+connect to the MGS, to MDTS on MDSs, and to OSTs on OSSs. Furthermore,
+MDSs and OSSs will connect to the MGS, and MDSs will connect to OSTs
+on OSSs. In each case the host initiating the the connection request
+sends an 'obd_connect_client' message. The reply to this message is
+the obd_connect_server message.
+
+.format
+[options="header"]
+|====
+| structure        | meaning
+| ptlrpc_body      | RPC descriptor
+| obd_uuid         | UUID of the target
+| obd_uuid         | UUID of the client
+| lustre_handle    | connection handle
+| obd_connect_data | connection data
+|====
+
+An 'obd_connect_client' message concatenates five data elements into
+a single byte-stream. The five elements correspond to structures
+detailed in the <<data-structs,Data Structures and Defines Section>>.
+
+The connection handle sent in a client connection request message is
+unique to that connection. The server notes it and a connection
+request with a new or different handle indicates that the client is
+attempting to make a new connection (or a delayed message about an
+old one?).
+
+The OBD Connect Server Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+' obd_connect_server'
+^^^^^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc      | pb_type
+| MDS_CONNECT | PTL_RPC_MSG_REPLY
+|====
+
+The 'obd_connect_server' mess-sage format is sent by a server in reply
+to an 'obd_connect_client' connection request message. to a target on
+that server. MGSs, MDSs, and OSSs send these replies.
+
+.format
+[options="header"]
+|====
+| structure        | meaning
+| ptlrpc_body      | RPC descriptor
+| obd_connect_data | connection data
+|====
+
+An 'obd_connect_server' message concatenates two data elements into a
+single byte-stream.
+
+The OBD Statfs Server Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+'obd_statfs_server'
+^^^^^^^^^^^^^^^^^^^
+
+.example
+[options="header"]
+|====
+| pb_opc     | pb_type
+| MDS_STATFS | PTL_RPC_MSG_REPLY
+|====
+
+The 'obd_statfs_server' message returns 'statfs' system call
+information to the client.
+
+.format
+[options="header"]
+|====
+| structure        | meaning
+| ptlrpc_body      | RPC descriptor
+| obd_statfs      | statfs system call info
+|====
+