1. 09 May, 2014 1 commit
  2. 06 May, 2014 2 commits
    • Klaus Aehlig's avatar
      Simplify cleanup of locks · 0d730682
      Klaus Aehlig authored
      
      
      Since, from stable-2.12 onwards, locks are no longer explicitly
      added and removed, there is no need to release them separately.
      The freeing of all locks of the level left will take care of this
      anyway.
      Signed-off-by: default avatarKlaus Aehlig <aehlig@google.com>
      Reviewed-by: default avatarPetr Pudlak <pudlak@google.com>
      0d730682
    • Klaus Aehlig's avatar
      Handle lock addition as lock acquisitions · bb38965c
      Klaus Aehlig authored
      
      
      From stable-2.12 onwards no longer are explicitly added; they just
      exist for all conceivable names/uuids. Nevertheless, addition was
      handled special based on the assumption that no one else can have
      a lock on an entity that is just being created.
      
      This assumption, however, is wrong for instance names. Consider
      the situation that an instance is first destroyed an then an instance
      with the same name is created. While is instance is being destroyed,
      there is the situation where the instance is still in the configuration
      and the destroy job holds a lock on the instance. In that time, another
      job, like group_verify_disks, can read the list of instances, decide
      to wait for a lock on all the then existing instances, and eventually
      get the locks, including the one on the instance just removed. And
      while that job still has the (useless) lock, the new creation job can
      come to the lock-addition stage.
      
      To live with the presence of those races, just wait for newly added
      locks as for any other locks. Any job with a lock on a no longer existing
      entity will release it pretty soon anyway.
      Signed-off-by: default avatarKlaus Aehlig <aehlig@google.com>
      Reviewed-by: default avatarPetr Pudlak <pudlak@google.com>
      bb38965c
  3. 05 May, 2014 18 commits
  4. 02 May, 2014 1 commit
  5. 28 Apr, 2014 3 commits
  6. 27 Apr, 2014 1 commit
  7. 25 Apr, 2014 4 commits
  8. 24 Apr, 2014 5 commits
  9. 22 Apr, 2014 2 commits
  10. 17 Apr, 2014 3 commits