-
Export
^^^^^^
-
+[[obd-export]]
An 'obd_export' structure for a given target is created on a server
for each client that connects to that target. The exports for all the
clients for a given target are managed together. The export represents
current state of any ongoing activity. Thus each pending request will
have a reference to the export. The export is discarded if the
connection goes away, but only after all the references to it have
-been cleaned up. The state information for each export is also
-maintained on disk. In the event of a server failure, that or another
-server can read the export date from disk to enable recovery.
+been cleaned up. Some state information for each export is also
+maintained on disk. In the event of a server failure and recovery,
+the server can read the export data from disk to allow the client
+to reconnect and participate in recovery, otherwise a client without
+any export data will not be allowed to participate in recovery.
----
struct obd_export {
- struct portals_handle exp_handle;
- atomic_t exp_refcount;
- atomic_t exp_rpc_count;
- atomic_t exp_cb_count;
- atomic_t exp_replay_count;
- atomic_t exp_locks_count;
-#if LUSTRE_TRACKS_LOCK_EXP_REFS
- cfs_list_t exp_locks_list;
- spinlock_t exp_locks_list_guard;
-#endif
- struct obd_uuid exp_client_uuid;
- cfs_list_t exp_obd_chain;
- cfs_hlist_node_t exp_uuid_hash;
- cfs_hlist_node_t exp_nid_hash;
- cfs_list_t exp_obd_chain_timed;
- struct obd_device *exp_obd;
- struct obd_import *exp_imp_reverse;
- struct nid_stat *exp_nid_stats;
- struct ptlrpc_connection *exp_connection;
- __u32 exp_conn_cnt;
- cfs_hash_t *exp_lock_hash;
- cfs_hash_t *exp_flock_hash;
- cfs_list_t exp_outstanding_replies;
- cfs_list_t exp_uncommitted_replies;
- spinlock_t exp_uncommitted_replies_lock;
- __u64 exp_last_committed;
- cfs_time_t exp_last_request_time;
- cfs_list_t exp_req_replay_queue;
- spinlock_t exp_lock;
- struct obd_connect_data exp_connect_data;
- enum obd_option exp_flags;
- unsigned long
- exp_failed:1,
- exp_in_recovery:1,
- exp_disconnected:1,
- exp_connecting:1,
- exp_delayed:1,
- exp_vbr_failed:1,
- exp_req_replay_needed:1,
- exp_lock_replay_needed:1,
- exp_need_sync:1,
- exp_flvr_changed:1,
- exp_flvr_adapt:1,
- exp_libclient:1,
- exp_need_mne_swab:1;
- enum lustre_sec_part exp_sp_peer;
- struct sptlrpc_flavor exp_flvr;
- struct sptlrpc_flavor exp_flvr_old[2];
- cfs_time_t exp_flvr_expire[2];
- spinlock_t exp_rpc_lock;
- cfs_list_t exp_hp_rpcs;
- cfs_list_t exp_reg_rpcs;
- cfs_list_t exp_bl_list;
- spinlock_t exp_bl_list_lock;
- union {
- struct tg_export_data eu_target_data;
- struct mdt_export_data eu_mdt_data;
- struct filter_export_data eu_filter_data;
- struct ec_export_data eu_ec_data;
- struct mgs_export_data eu_mgs_data;
- } u;
- struct nodemap *exp_nodemap;
+ struct portals_handle exp_handle;
+ struct obd_uuid exp_client_uuid;
+ struct obd_connect_data exp_connect_data;
};
----
-The 'exp_handle' is a little extra information as compared with a
-'struct lustre_handle', which is just the cookie. The cookie that the
-server generates to uniquely identify this connection gets put into
-this structure along with their information about the device in
-question. This is the cookie the *_CONNECT reply sends back to the
-client and is then stored int he client's import.
+//////////////////////////////////////////////////////////////////////
+////vvvv
+This is the full obd_export.
+
+struct obd_export {
+ struct portals_handle exp_handle;
+ atomic_t exp_refcount;
+ atomic_t exp_rpc_count;
+ atomic_t exp_cb_count;
+ atomic_t exp_replay_count;
+ atomic_t exp_locks_count;
+ struct obd_uuid exp_client_uuid;
+ cfs_list_t exp_obd_chain;
+ cfs_hlist_node_t exp_uuid_hash;
+ cfs_hlist_node_t exp_nid_hash;
+ cfs_list_t exp_obd_chain_timed;
+ struct obd_device *exp_obd;
+ struct obd_import *exp_imp_reverse;
+ struct nid_stat *exp_nid_stats;
+ struct ptlrpc_connection *exp_connection;
+ __u32 exp_conn_cnt;
+ cfs_hash_t *exp_lock_hash;
+ cfs_hash_t *exp_flock_hash;
+ cfs_list_t exp_outstanding_replies;
+ cfs_list_t exp_uncommitted_replies;
+ spinlock_t exp_uncommitted_replies_lock;
+ __u64 exp_last_committed;
+ cfs_time_t exp_last_request_time;
+ cfs_list_t exp_req_replay_queue;
+ spinlock_t exp_lock;
+ struct obd_connect_data exp_connect_data;
+ enum obd_option exp_flags;
+ unsigned long
+ exp_failed:1,
+ exp_in_recovery:1,
+ exp_disconnected:1,
+ exp_connecting:1,
+ exp_delayed:1,
+ exp_vbr_failed:1,
+ exp_req_replay_needed:1,
+ exp_lock_replay_needed:1,
+ exp_need_sync:1,
+ exp_flvr_changed:1,
+ exp_flvr_adapt:1,
+ exp_libclient:1,
+ exp_need_mne_swab:1;
+ enum lustre_sec_part exp_sp_peer;
+ struct sptlrpc_flavor exp_flvr;
+ struct sptlrpc_flavor exp_flvr_old[2];
+ cfs_time_t exp_flvr_expire[2];
+ spinlock_t exp_rpc_lock;
+ cfs_list_t exp_hp_rpcs;
+ cfs_list_t exp_reg_rpcs;
+ cfs_list_t exp_bl_list;
+ spinlock_t exp_bl_list_lock;
+ union {
+ struct tg_export_data eu_target_data;
+ struct mdt_export_data eu_mdt_data;
+ struct filter_export_data eu_filter_data;
+ struct ec_export_data eu_ec_data;
+ struct mgs_export_data eu_mgs_data;
+ } u;
+ struct nodemap *exp_nodemap;
+};
+////^^^^
+//////////////////////////////////////////////////////////////////////
+
+The 'exp_handle' holds the cookie that the server generates at
+*_CONNECT time to uniquely identify this connection from the client.
+This cookie is also sent back to the client in the reply and is
+then stored in the client's import.
+//////////////////////////////////////////////////////////////////////
+////vvvv
The 'exp_refcount' gets incremented whenever some aspect of the export
is "in use". The arrival of an otherwise unprocessed message for this
target will increment the refcount. A reference by an LDLM lock that
purposes. Similarly, the 'exp_locks_list' and 'exp_locks_list_guard'
are further debug info that list the actual locks accounted for in
'exp_locks_count'.
+////^^^^
+//////////////////////////////////////////////////////////////////////
-The 'exp_client_uuid' gives the UUID of the client connected to this
-export. Fixme: when and how does the UUID get generated?
+The 'exp_client_uuid' holds the UUID of the client connected to this
+export. This UUID is randomly generated by the client and the same
+UUID is used by the client for connecting to all servers, so that
+the servers may identify the client amongst themselves if necessary.
+//////////////////////////////////////////////////////////////////////
+////vvvv
The server maintains all the exports for a given target on a circular
list. Each export's place on that list is maintained in the
'exp_obd_chain'. A common activity is to look up the export based on
export. This is the information about the actual networking pathway(s)
that get used for communication.
-
The 'exp_conn_cnt' notes the connection count value from the client at
the time of the connection. In the event that more than one connection
request is issued before the connection is established then the
The 'exp_lock' spin-lock is used for access control to the exports
flags, as well as the 'exp_outstanding_replies' list and the revers
import, if any.
+////^^^^
+//////////////////////////////////////////////////////////////////////
The 'exp_connect_data' refers to an 'obd_connect_data' structure for
the connection established between this target and the client this
-export refers to. See also the corresponding entry in the import and
+export refers to. The 'exp_connect_data' describes the mutually
+supported features that were negotiated between the client and server
+at connect time. See also the corresponding entry in the import and
in the connect messages passed between the hosts.
+//////////////////////////////////////////////////////////////////////
+////vvvv
The 'exp_flags' field encodes three directives as follows:
----
enum obd_option {
The 'exp_bl_lock_at' field supports adaptive timeouts which will be
discussed separately. (fixme: so discuss it somewhere.)
-
+////^^^^
+//////////////////////////////////////////////////////////////////////
git://git.whamcloud.com / doc / protocol.git / blobdiff