Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 10月, 2012 10 次提交
  3. 17 10月, 2012 6 次提交
  5. 16 10月, 2012 1 次提交
  7. 13 10月, 2012 5 次提交
  9. 12 10月, 2012 12 次提交
  11. 11 10月, 2012 6 次提交
    • 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
    • N
      md: make sure manual changes to recovery checkpoint are saved. · db07d85e
      由 NeilBrown 提交于 
      If you make an array bigger but suppress resync of the new region with
  mdadm --grow /dev/mdX --size=max --assume-clean

then stop the array before anything is written to it, the effect of
the "--assume-clean" is lost and the array will resync the new space
when restarted.
So ensure that we update the metadata in the case.
Reported-by: NSebastian Riemer <sebastian.riemer@profitbricks.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      db07d85e
    • D
      md/raid10: use correct limit variable · 91502f09
      由 Dan Carpenter 提交于 
      Clang complains that we are assigning a variable to itself.  This should
be using bad_sectors like the similar earlier check does.

Bug has been present since 3.1-rc1.  It is minor but could
conceivably cause corruption or other bad behaviour.

Cc: stable@vger.kernel.org
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      91502f09
    • N
      md: writing to sync_action should clear the read-auto state. · 48c26ddc
      由 NeilBrown 提交于 
      In some cases array are started in 'read-auto' state where in
nothing gets written to any device until the array is written
to.  The purpose of this is to make accidental auto-assembly
of the wrong arrays less of a risk, and to allow arrays to be
started to read suspend-to-disk images without actually changing
anything (as might happen if the array were dirty and a
resync seemed necessary).

Explicitly writing the 'sync_action' for a read-auto array currently
doesn't clear the read-auto state, so the sync action doesn't
happen, which can be confusing.

So allow any successful write to sync_action to clear any read-auto
state.
Reported-by: NAlexander Kühn <alexander.kuehn@nagilum.de>
Signed-off-by: NNeilBrown <neilb@suse.de>
      48c26ddc
    • J
      Subject: [PATCH] md:change resync_mismatches to atomic64_t to avoid races · 7f7583d4
      由 Jianpeng Ma 提交于 
      Now that multiple threads can handle stripes, it is safer to
use an atomic64_t for resync_mismatches, to avoid update races.
Signed-off-by: NJianpeng Ma <majianpeng@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      7f7583d4