OBD Connect Data
^^^^^^^^^^^^^^^^
-[[struct-obd-connect-data]]
-
An 'obd_connect_data' structure accompanies every connect operation in
both the request message and in the reply message. It contains the
mutually supported features that are negotiated between the client and
server at *_CONNECT time.
-At *_CONNECT time the client sends in its request 'ocd_connect_flags'
-the flags for all features that it understands and intends to use (for
-example 'OBD_CONNECT_RDONLY' is optional depending on client mount
-options). The request also contains other fields that are only valid
-if the matching flag is set. The server replies in 'ocd_connect_flags'
-with the subset of feature flags that it understands and intends to honour.
-The server may set fields in the reply for mutually-understood features.
-
+.The OBD Connect Data Structure
+[[struct-obd-connect-data]]
+****
[source,c]
----
struct obd_connect_data {
__u64 paddingF;
};
----
+****
+
+At *_CONNECT time the client sends in its request 'ocd_connect_flags'
+the flags for all features that it understands and intends to use (for
+example 'OBD_CONNECT_RDONLY' is optional depending on client mount
+options). The request also contains other fields that are only valid
+if the matching flag is set. The server replies in 'ocd_connect_flags'
+with the subset of feature flags that it understands and intends to honour.
+The server may set fields in the reply for mutually-understood features.
The 'ocd_connect_flags' field encodes the connect flags giving the
capabilities of a connection between client and target. Several of
server then replies with the subset of those capabilities it agrees to
honor (for the given target).
-If the 'OBD_CONNECT_VERSION' flag is set then the 'ocd_version' field is
-valid. The 'ocd_version' gives an encoding of the Lustre
-version. For example, Version 2.7.55 would be hexadecimal number
-0x02075500.
+If the 'OBD_CONNECT_VERSION' flag is set then the 'ocd_version' field
+is valid. The 'ocd_version' gives an encoding of the Lustre
+version. The Lustre version itself is a four-tuple of decimal numbers
+(major, minor, patch, fix), with missing trailing values defaulting to
+zero. Each of the four numbers is shifted into place in the four bytes
+of the 'ocd_version'. For example, Version 2.7.55 would be
+hexadecimal number 0x02073700.
If the OBD_CONNECT_GRANT flag is set then the 'ocd_grant' field is
valid. The 'ocd_grant' value in a reply (to a connection request)
-sets the client's grant.
+initializes the client's grant. See <<grant>>.
If the OBD_CONNECT_INDEX flag is set then the 'ocd_index' field is
valid. The 'ocd_index' value is set in a request to hold the LOV
-index of the OST or the LMV index of the MDT. The server should
-refuse connections to targets for which the 'ocd_index' does not
-match the actual target index.
+index of the OST or the LMV index of the MDT. The server's export for
+the target holds the correct value, and if the client send a value
+that does not match the server returns the -EBDF error.
If the OBD_CONNECT_BRW_SIZE flag is set then the 'ocd_brw_size' field
is valid. The 'ocd_brw_size' value sets the maximum supported bulk
If the OBD_CONNECT_IBITS flag is set then the 'ocd_ibits_known' field
is valid. The 'ocd_ibits_known' flags determine the handling of
locks on MDS inodes. The OBD_CONNECT_IBITS flag was introduced in
-Lustre 1.4 and is mandatory for MDS_CONNECT RPCs. See also the discussion
-of inodes and extended attributes.
-[[mds-inode-bits-locks]]
+Lustre 1.4 and is mandatory for MDS_CONNECT RPCs.
[source,c]
----
A server reply uses the 'ocd_inodespace' value to inform the client of
the log base two of the size of an inode.
-Under some circumstances (for example when ZFS is the back end file
-system) there may be additional overhead in handling writes for each
-extent. The server uses the 'ocd_grant_extent' value to inform the
-client of the size in bytes consumed from its grant on the server when
-creating a new file. The client uses this value in calculating how
-much dirty write cache it has and whether it has reached the limit
-established by the target's grant.
+Under some circumstances (for example when the OSD is ZFS) there may
+be additional overhead in handling writes for each extent. The server
+uses the 'ocd_grant_extent' value to inform the client of the size in
+bytes consumed from its grant on the server when creating a new
+file. The client uses this value in calculating how much dirty write
+cache it has and whether it has reached the limit established by the
+target's grant.
If the OBD_CONNECT_TRANSNO flag is set then the 'ocd_transno' field is
honored. A server uses the 'ocd_transno' value during recovery to
git://git.whamcloud.com / doc / protocol.git / blobdiff