1. 19 Nov, 2012 1 commit
  2. 13 Oct, 2012 1 commit
  3. 02 May, 2012 1 commit
    • David Teigland's avatar
      dlm: fixes for nodir mode · 4875647a
      David Teigland authored
      The "nodir" mode (statically assign master nodes instead
      of using the resource directory) has always been highly
      experimental, and never seriously used.  This commit
      fixes a number of problems, making nodir much more usable.
      
      - Major change to recovery: recover all locks and restart
        all in-progress operations after recovery.  In some
        cases it's not possible to know which in-progess locks
        to recover, so recover all.  (Most require recovery
        in nodir mode anyway since rehashing changes most
        master nodes.)
      
      - Change the way nodir mode is enabled, from a command
        line mount arg passed through gfs2, into a sysfs
        file managed by dlm_controld, consistent with the
        other config settings.
      
      - Allow recovering MSTCPY locks on an rsb that has not
        yet been turned into a master copy.
      
      - Ignore RCOM_LOCK and RCOM_LOCK_REPLY recovery messages
        from a previous, aborted recovery cycle.  Base this
        on the local recovery status not being in the state
        where any nodes should be sending LOCK messages for the
        current recovery cycle.
      
      - Hold rsb lock around dlm_purge_mstcpy_locks() because it
        may run concurrently with dlm_recover_master_copy().
      
      - Maintain highbast on process-copy lkb's (in addition to
        the master as is usual), because the lkb can switch
        back and forth between being a master and being a
        process copy as the master node changes in recovery.
      
      - When recovering MSTCPY locks, flag rsb's that have
        non-empty convert or waiting queues for granting
        at the end of recovery.  (Rename flag from LOCKS_PURGED
        to RECOVER_GRANT and similar for the recovery function,
        because it's not only resources with purged locks
        that need grant a grant attempt.)
      
      - Replace a couple of unnecessary assertion panics with
        error messages.
      Signed-off-by: David Teigland's avatarDavid Teigland <teigland@redhat.com>
      4875647a
  4. 04 Jan, 2012 1 commit
    • David Teigland's avatar
      dlm: add recovery callbacks · 60f98d18
      David Teigland authored
      These new callbacks notify the dlm user about lock recovery.
      GFS2, and possibly others, need to be aware of when the dlm
      will be doing lock recovery for a failed lockspace member.
      
      In the past, this coordination has been done between dlm and
      file system daemons in userspace, which then direct their
      kernel counterparts.  These callbacks allow the same
      coordination directly, and more simply.
      Signed-off-by: David Teigland's avatarDavid Teigland <teigland@redhat.com>
      60f98d18
  5. 07 Sep, 2010 1 commit
  6. 07 May, 2009 1 commit
  7. 28 Aug, 2008 1 commit
    • David Teigland's avatar
      dlm: allow multiple lockspace creates · 0f8e0d9a
      David Teigland authored
      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's avatarDavid Teigland <teigland@redhat.com>
      0f8e0d9a
  8. 21 Apr, 2008 2 commits
  9. 25 Jan, 2008 1 commit
  10. 09 Jul, 2007 3 commits
    • Patrick Caulfield's avatar
      [DLM] variable allocation · 44f487a5
      Patrick Caulfield authored
      Add a new flag, DLM_LSFL_FS, to be used when a file system creates a lockspace.
      This flag causes the dlm to use GFP_NOFS for allocations instead of GFP_KERNEL.
      (This updated version of the patch uses gfp_t for ls_allocation.)
      Signed-Off-By: default avatarPatrick Caulfield <pcaulfie@redhat.com>
      Signed-Off-By: David Teigland's avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: Steven Whitehouse's avatarSteven Whitehouse <swhiteho@redhat.com>
      44f487a5
    • David Teigland's avatar
      [DLM] cancel in conversion deadlock [4/6] · c85d65e9
      David Teigland authored
      When conversion deadlock is detected, cancel the conversion and return
      EDEADLK to the application.  This is a new default behavior where before
      the dlm would allow the deadlock to exist indefinately.
      
      The DLM_LKF_NODLCKWT flag can now be used in a conversion to prevent the
      dlm from performing conversion deadlock detection/cancelation on it.
      The DLM_LKF_CONVDEADLK flag can continue to be used as before to tell the
      dlm to demote the granted mode of the lock being converted if it gets into
      a conversion deadlock.
      Signed-off-by: David Teigland's avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: Steven Whitehouse's avatarSteven Whitehouse <swhiteho@redhat.com>
      c85d65e9
    • David Teigland's avatar
      [DLM] add lock timeouts and warnings [2/6] · 3ae1acf9
      David Teigland authored
      New features: lock timeouts and time warnings.  If the DLM_LKF_TIMEOUT
      flag is set, then the request/conversion will be canceled after waiting
      the specified number of centiseconds (specified per lock).  This feature
      is only available for locks requested through libdlm (can be enabled for
      kernel dlm users if there's a use for it.)
      
      If the new DLM_LSFL_TIMEWARN flag is set when creating the lockspace, then
      a warning message will be sent to userspace (using genetlink) after a
      request/conversion has been waiting for a given number of centiseconds
      (configurable per node).  The time warnings will be used in the future
      to do deadlock detection in userspace.
      Signed-off-by: David Teigland's avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: Steven Whitehouse's avatarSteven Whitehouse <swhiteho@redhat.com>
      3ae1acf9
  11. 23 Feb, 2006 1 commit
  12. 18 Jan, 2006 1 commit