The Lustre protocol is connection-based in that each two entities
maintain shared, coordinated state information. The most common
-example of two such entities are a client and a target on some
+example is the connection between a client and the target on some
server. The target is identified by name to the client through an
interaction with the management server. The client then 'connects' to
the given target on the indicated server by sending the appropriate
-version of the various *_CONNECT message (MGS_CONNECT, MDS_CONNECT, or
-OST_CONNECT) and receiving back the
-corresponding *_CONNECT reply. The server creates an 'export' for the
-connection between the target and the client, and the export holds the
-server state information for that connection. When the client gets the
-reply it creates an 'import', and the import holds the client state
-information for that connection. Note that if a server has N targets
-and M clients have connected to them, the server will have N x M
-exports and each client will have N imports.
+version of the various *_CONNECT messages (MGS_CONNECT, MDS_CONNECT,
+or OST_CONNECT) and receiving back the corresponding *_CONNECT
+reply. The server creates an 'export' (See <<struct-obd-export>>) for
+the connection between the target and the client, and the export holds
+the server state information for that connection. When the client gets
+the reply it creates an 'import' (See <<struct-obd-import>>), and the
+import holds the client state information for that connection. Note
+that if a server has N targets and M clients have connected to them,
+the server will have N x M exports and each client will have N
+imports.
There are also connections between the servers: Each MDS and OSS has a
connection to the MGS, where the MDS (respectively the OSS) plays the
role of the client in the above discussion. That is, the MDS initiates
the connection and has an import for the MGS, while the MGS has an
export for each MDS. Each MDS creates an 'object storage proxy' (OSP)
-connection to each OST, with an import on
-the MDS and an export on the OSS. This connection supports requests
-from the MDS to the OST to create and destroy data objects, to set
-attributes (such as permission bits), and for 'statfs' information for
-precreation needs. Each OSS also connects to the first MDS to get
-access to auxiliary services, with an import on the OSS and an export
-on the first MDS. The auxiliary services are: the File ID Location
-Database (FLDB), the quota master service, and the sequence
-controller. This connection for auxiliary services is a 'light weight
-proxy' (LWP) connection in that it has no replay functionality and
-consumes no space on the MDS for client data. Each MDS connects also
-to all other MDSs for DNE needs.
+connection to each OST, with an import on the MDS and an export on the
+OSS. This connection supports requests from the MDS to the OST to
+create and destroy data objects, to set attributes (such as permission
+bits), and for 'statfs' information for precreation needs. Each OSS
+also connects to the first MDS to get access to auxiliary services,
+with an import on the OSS and an export on the first MDS. The
+auxiliary services are: the File ID Location Database (FLDB), the
+quota master service, and the sequence controller. This connection for
+auxiliary services is a 'light weight proxy' (LWP) connection in that
+it has no replay functionality (See <<recovery>>) and consumes no
+space on the MDS for client data. Each MDS also connects to all other
+MDSs for DNE needs.
Finally, for some communications the roles of message initiation and
message reply are reversed. This is the case, for instance, with
reverse-import uses the same structure as a regular import, and the
reverse-export uses the same structure as a regular export.
-include::obd_connect_data.txt[]
+include::struct_obd_connect_data.txt[]
-include::import.txt[]
+include::struct_obd_import.txt[]
-include::export.txt[]
+include::struct_obd_export.txt[]
include::timeouts.txt[]
git://git.whamcloud.com / doc / protocol.git / blobdiff