From: Ned Bass <ba...@llnl.gov>

As this lock can be a bottleneck, clarifying why it is needed may be
helpful to those working on client performance.

Signed-off-by: Ned Bass <ba...@llnl.gov>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3443
Reviewed-on: http://review.whamcloud.com/6593
Reviewed-by: Andreas Dilger <andreas.dil...@intel.com>
Reviewed-by: Keith Mannthey <keith.mannt...@intel.com>
Signed-off-by: James Simmons <jsimm...@infradead.org>
---
 drivers/staging/lustre/lustre/include/lustre_mdc.h |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_mdc.h 
b/drivers/staging/lustre/lustre/include/lustre_mdc.h
index df94f9f..9e54790 100644
--- a/drivers/staging/lustre/lustre/include/lustre_mdc.h
+++ b/drivers/staging/lustre/lustre/include/lustre_mdc.h
@@ -64,9 +64,27 @@ struct obd_export;
 struct ptlrpc_request;
 struct obd_device;
 
+/**
+ * Serializes in-flight MDT-modifying RPC requests to preserve idempotency.
+ *
+ * This mutex is used to implement execute-once semantics on the MDT.
+ * The MDT stores the last transaction ID and result for every client in
+ * its last_rcvd file. If the client doesn't get a reply, it can safely
+ * resend the request and the MDT will reconstruct the reply being aware
+ * that the request has already been executed. Without this lock,
+ * execution status of concurrent in-flight requests would be
+ * overwritten.
+ *
+ * This design limits the extent to which we can keep a full pipeline of
+ * in-flight requests from a single client.  This limitation could be
+ * overcome by allowing multiple slots per client in the last_rcvd file.
+ */
 struct mdc_rpc_lock {
+       /** Lock protecting in-flight RPC concurrency. */
        struct mutex            rpcl_mutex;
+       /** Intent associated with currently executing request. */
        struct lookup_intent    *rpcl_it;
+       /** Used for MDS/RPC load testing purposes. */
        int                     rpcl_fakes;
 };
 
-- 
1.7.1

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to