11 Mar, 2011

1 commit

  • Change how callbacks are recorded for locks. Previously, information
    about multiple callbacks was combined into a couple of variables that
    indicated what the end result should be. In some situations, we
    could not tell from this combined state what the exact sequence of
    callbacks were, and would end up either delivering the callbacks in
    the wrong order, or suppress redundant callbacks incorrectly. This
    new approach records all the data for each callback, leaving no
    uncertainty about what needs to be delivered.

    Signed-off-by: David Teigland

    David Teigland
     

25 Feb, 2010

1 commit

  • 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: David Teigland

    David Teigland
     

24 Dec, 2008

1 commit

  • The lkb bastmode value is set in the context of processing the
    lock, and read by the dlm_astd thread. Because it's accessed
    in these two separate contexts, the writing/reading ought to
    be done under a lock. This is simple to do by setting it and
    reading it when the lkb is added to and removed from dlm_astd's
    callback list which is properly locked.

    Signed-off-by: David Teigland

    David Teigland
     

29 Aug, 2008

2 commits

  • If dlm_controld (the userspace daemon that controls the setup and
    recovery of the dlm) fails, the kernel should shut down the lockspaces
    in the kernel rather than leaving them running. This is detected by
    having dlm_controld hold a misc device open while running, and if
    the kernel detects a close while the daemon is still needed, it stops
    the lockspaces in the kernel.

    Knowing that the userspace daemon isn't running also allows the
    lockspace create/remove routines to avoid waiting on the daemon
    for join/leave operations.

    Signed-off-by: David Teigland

    David Teigland
     
  • Add a count for lockspace create and release so that create can
    be called multiple times to use the lockspace from different places.
    Also add the new flag DLM_LSFL_NEWEXCL to create a lockspace with
    the previous behavior of returning -EEXIST if the lockspace already
    exists.

    Signed-off-by: David Teigland

    David Teigland
     

13 Jul, 2006

1 commit

  • This changes the way the dlm handles user locks. The core dlm is now
    aware of user locks so they can be dealt with more efficiently. There is
    no more dlm_device module which previously managed its own duplicate copy
    of every user lock.

    Signed-off-by: Patrick Caulfield
    Signed-off-by: David Teigland
    Signed-off-by: Steven Whitehouse

    David Teigland