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