Whamcloud - gitweb
LUDOC 299 protocol: Spell-check document
[doc/protocol.git] / early_lock_cancellation.txt
index ee4dbea..8929e44 100644 (file)
@@ -2,17 +2,28 @@ Early Lock Cancellation
 ^^^^^^^^^^^^^^^^^^^^^^^
 [[early-lock-cancellation]]
 
-In some circumstances (see <<mds-reint-setattr-rpc>>) a client holding
-a lock "knows" that the operation it is initiating will necessitate
-canceling a lock that it holds. In such a circumstance the lock is
-said to be "in conflict" with the operation. For example, a side
-effect of the GNU 'fileutils' is that it always issues a 'stat' prior
-to other update operations, so when issuing an update to a resource
-attribute on the MDT a) the client will already have a read lock on
-the resource, and b) the MDT will then need a lock on that same
-resource in order to perform the update. Rather than waiting for an
-additional round of RPCs to carry out the lock cancellation (on the
-client) the RPC requesting the update can include a cancellation of
-the lock as part of its request. This proactive lock cancellation is
-called "early lock cancellation" or sometimes ELC.
+In some circumstances (see for example <<mds-reint-setattr-rpc>>) a
+client holding a lock "knows" that the operation it is initiating will
+necessitate canceling a lock that it holds. In such a circumstance the
+lock is said to be "in conflict" with the operation. For example, a
+side effect of GNU 'fileutils' is that it often issues a 'stat()' on a
+file prior to other update operations such as 'unlink()', so when
+issuing an update to a resource attribute on the MDT a) the client
+will already have a read lock on the resource, and b) the MDT will
+then need a lock on that same resource in order to perform the
+update. Rather than waiting for an additional round of RPCs to carry
+out the lock cancellation (on the client) the RPC requesting the
+update can include a cancellation of one or more locks as part of its
+request. This proactive lock cancellation is called "early lock
+cancellation" or sometimes ELC.
 
+ELC can also proactively cancel unused cached locks on the client
+from the lock LRU list to avoid the need for later lock callbacks
+(if the lock is needed on another client) or to avoid extra lock
+cancellation RPCs if the number of cached locks on the client becomes
+too large.
+
+ELC lock cancellation is only possible for locks that reside on the
+target to which the RPC is being sent.  It is not possible to cancel
+locks via ELC on a different target, even if that target is serviced
+by the same server.