^^^^^^^^^^^^^^^^^^^^^^^
[[early-lock-cancellation]]
-In some circumstances (see <<mds-reint-setattr-rpc>>) a client holding
+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 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
+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
-the lock as part of its request. This proactive lock cancellation is
-called "early lock cancellation" or sometimes ELC.
+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.
git://git.whamcloud.com / doc / protocol.git / blobdiff