1. 26 Feb, 2010 1 commit
    • David Teigland's avatar
      dlm: send reply before bast · cf6620ac
      David Teigland authored
      When the lock master processes a successful operation (request,
      convert, cancel, or unlock), it will process the effects of the
      change before sending the reply for the operation.  The "effects"
      of the operation are:
      
      - blocking callbacks (basts) for any newly granted locks
      - waiting or converting locks that can now be granted
      
      The cast is queued on the local node when the reply from the lock
      master is received.  This means that a lock holder can receive a
      bast for a lock mode that is doesn't yet know has been granted.
      Signed-off-by: default avatarDavid Teigland <teigland@redhat.com>
      cf6620ac
  2. 24 Feb, 2010 1 commit
    • David Teigland's avatar
      dlm: fix ordering of bast and cast · 7fe2b319
      David Teigland authored
      When both blocking and completion callbacks are queued for lock,
      the dlm would always deliver the completion callback (cast) first.
      In some cases the blocking callback (bast) is queued before the
      cast, though, and should be delivered first.  This patch keeps
      track of the order in which they were queued and delivers them
      in that order.
      
      This patch also keeps track of the granted mode in the last cast
      and eliminates the following bast if the bast mode is compatible
      with the preceding cast mode.  This happens when a remotely mastered
      lock is demoted, e.g. EX->NL, in which case the local node queues
      a cast immediately after sending the demote message.  In this way
      a cast can be queued for a mode, e.g. NL, that makes an in-transit
      bast extraneous.
      Signed-off-by: default avatarDavid Teigland <teigland@redhat.com>
      7fe2b319
  3. 17 Feb, 2010 4 commits
  4. 16 Feb, 2010 34 commits