early_lock_cancellation.txt

   1 Early Lock Cancellation
   2 ^^^^^^^^^^^^^^^^^^^^^^^
   3 [[early-lock-cancellation]]
   4
   5 In some circumstances (see for example <<mds-reint-setattr-rpc>>) a
   6 client holding a lock "knows" that the operation it is initiating will
   7 necessitate canceling a lock that it holds. In such a circumstance the
   8 lock is said to be "in conflict" with the operation. For example, a
   9 side effect of GNU 'fileutils' is that it often issues a 'stat()' on a
  10 file prior to other update operations such as 'unlink()', so when
  11 issuing an update to a resource attribute on the MDT a) the client
  12 will already have a read lock on the resource, and b) the MDT will
  13 then need a lock on that same resource in order to perform the
  14 update. Rather than waiting for an additional round of RPCs to carry
  15 out the lock cancellation (on the client) the RPC requesting the
  16 update can include a cancellation of one or more locks as part of its
  17 request. This proactive lock cancellation is called "early lock
  18 cancellation" or sometimes ELC.
  19
  20 ELC can also proactively cancel unused cached locks on the client
  21 from the lock LRU list to avoid the need for later lock callbacks
  22 (if the lock is needed on another client) or to avoid extra lock
  23 cancellation RPCs if the number of cached locks on the client becomes
  24 too large.
  25
  26 ELC lock cancellation is only possible for locks that reside on the
  27 target to which the RPC is being sent.  It is not possible to cancel
  28 locks via ELC on a different target, even if that target is serviced
  29 by the same server.