Early Lock Cancellation ^^^^^^^^^^^^^^^^^^^^^^^ [[early-lock-cancellation]] In some circumstances (see for example <>) 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.