1. 31 10月, 2012 19 次提交
  2. 16 10月, 2012 2 次提交
  3. 13 10月, 2012 5 次提交
  4. 12 10月, 2012 12 次提交
  5. 11 10月, 2012 2 次提交
    • N
      md: refine reporting of resync/reshape delays. · 72f36d59
      NeilBrown 提交于
      If 'resync_max' is set to 0 (as is often done when starting a
      reshape, so the mdadm can remain in control during a sensitive
      period), and if the reshape request is initially delayed because
      another array using the same array is resyncing or reshaping etc,
      when user-space cannot easily tell when the delay changes from being
      due to a conflicting reshape, to being due to resync_max = 0.
      
      So introduce a new state: (curr_resync == 3) to reflect this, make
      sure it is visible both via /proc/mdstat and via the "sync_completed"
      sysfs attribute, and ensure that the event transition from one delay
      state to the other is properly notified.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      72f36d59
    • N
      md/raid5: be careful not to resize_stripes too big. · e56108d6
      NeilBrown 提交于
      When a RAID5 is reshaping, conf->raid_disks is increased
      before mddev->delta_disks becomes zero.
      This can result in check_reshape calling resize_stripes with a
      number that is too large.  This particularly happens
      when md_check_recovery calls ->check_reshape().
      
      If we use ->previous_raid_disks, we don't risk this.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      e56108d6