1. 18 Aug, 2009 1 commit
  2. 13 Aug, 2009 4 commits
    • NeilBrown's avatar
      md: allow upper limit for resync/reshape to be set when array is read-only · 4d484a4a
      NeilBrown authored
      Normally we only allow the upper limit for a reshape to be decreased
      when the array not performing a sync/recovery/reshape, otherwise there
      could be races.  But if an array is part-way through a reshape when it
      is assembled the reshape is started immediately leaving no window
      to set an upper bound.
      
      If the array is started read-only, the reshape will be suspended until
      the array becomes writable, so that provides a window during which it
      is perfectly safe to reduce the upper limit of a reshape.
      
      So: allow the upper limit (sync_max) to be reduced even if the reshape
      thread is running, as long as the array is still read-only.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      4d484a4a
    • NeilBrown's avatar
      md/raid5: Properly remove excess drives after shrinking a raid5/6 · 1a67dde0
      NeilBrown authored
      We were removing the drives, from the array, but not
      removing symlinks from /sys/.... and not marking the device
      as having been removed.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      1a67dde0
    • NeilBrown's avatar
      md/raid5: make sure a reshape restarts at the correct address. · a639755c
      NeilBrown authored
      This "if" don't allow for the possibility that the number of devices
      doesn't change, and so sector_nr isn't set correctly in that case.
      So change '>' to '>='.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      a639755c
    • NeilBrown's avatar
      md/raid5: allow new reshape modes to be restarted in the middle. · 67ac6011
      NeilBrown authored
      md/raid5 doesn't allow a reshape to restart if it involves writing
      over the same part of disk that it would be reading from.
      This happens at the beginning of a reshape that increases the number
      of devices, at the end of a reshape that decreases the number of
      devices, and continuously for a reshape that does not change the
      number of devices.
      
      The current code is correct for the "increase number of devices"
      case as the critical section at the start is handled by userspace
      performing a backup.
      
      It does not work for reducing the number of devices, or the
      no-change case.
      For 'reducing', we need to invert the test.  For no-change we cannot
      really be sure things will be safe, so simply require the array
      to be read-only, which is how the user-space code which carefully
      starts such arrays works.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      67ac6011
  3. 12 Aug, 2009 1 commit
    • NeilBrown's avatar
      md: never advance 'events' counter by more than 1. · 51d5668c
      NeilBrown authored
      When assembling arrays, md allows two devices to have different event
      counts as long as the difference is only '1'.  This is to cope with
      a system failure between updating the metadata on two difference
      devices.
      
      However there are currently times when we update the event count by
      2.  This was done to keep the event count even when the array is clean
      and odd when it is dirty, which allows us to avoid writing common
      update to spare devices and so allow those spares to go to sleep.
      
      This is bad for the above reason.  So change it to never increase by
      two.  This means that the alignment between 'odd/even' and
      'clean/dirty' might take a little longer to attain, but that is only a
      small cost.  The spares will get a few more updates but that will
      still be spared (;-) most updates and can still go to sleep.
      
      Prior to this patch there was a small chance that after a crash an
      array would fail to assemble due to the overly large event count
      mismatch.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      51d5668c
  4. 10 Aug, 2009 1 commit
    • NeilBrown's avatar
      Remove deadlock potential in md_open · c8c00a69
      NeilBrown authored
      A recent commit:
        commit 449aad3e
      
      introduced the possibility of an A-B/B-A deadlock between
      bd_mutex and reconfig_mutex.
      
      __blkdev_get holds bd_mutex while calling md_open which takes
         reconfig_mutex,
      do_md_run is always called with reconfig_mutex held, and it now
         takes bd_mutex in the call the revalidate_disk.
      
      This potential deadlock was not caught by lockdep due to the
      use of mutex_lock_interruptible_nexted which was introduced
      by
         commit d63a5a74
      do avoid a warning of an impossible deadlock.
      
      It is quite possible to split reconfig_mutex in to two locks.
      One protects the array data structures while it is being
      reconfigured, the other ensures that an array is never even partially
      open while it is being deactivated.
      In particular, the second lock prevents an open from completing
      between the time when do_md_stop checks if there are any active opens,
      and the time when the array is either set read-only, or when ->pers is
      set to NULL.  So we can be certain that no IO is in flight as the
      array is being destroyed.
      
      So create a new lock, open_mutex, just to ensure exclusion between
      'open' and 'stop'.
      
      This avoids the deadlock and also avoids the lockdep warning mentioned
      in commit d63a5a74Reported-by: default avatar"Mike Snitzer" <snitzer@gmail.com>
      Reported-by: default avatar"H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      c8c00a69
  5. 08 Aug, 2009 5 commits
  6. 07 Aug, 2009 28 commits