[[early-lock-cancellation]]
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.
+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
git://git.whamcloud.com / doc / protocol.git / blobdiff