Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 12月, 2009 27 次提交
  3. 05 12月, 2009 1 次提交
  5. 01 12月, 2009 1 次提交
    • N
      md: revert incorrect fix for read error handling in raid1. · d0e26078
      由 NeilBrown 提交于 
      commit 4706b349 was a forward port of a fix that was needed
for SLES10.  But in fact it is not needed in mainline because
the earlier commit dd00a99e fixes the same problem in a
better way.
Further, this commit introduces a bug in the way it interacts with
the automatic read-error-correction.  If, after a read error is
successfully corrected, the same disk is chosen to re-read - the
re-read won't be attempted but an error will be returned instead.

After reverting that commit, there is the possibility that a
read error on a read-only array (where read errors cannot
be corrected as that requires a write) will repeatedly read the same
device and continue to get an error.
So in the "Array is readonly" case, fail the drive immediately on
a read error.
Signed-off-by: NNeilBrown <neilb@suse.de>
Cc: stable@kernel.org
      d0e26078
  7. 19 11月, 2009 1 次提交
  9. 13 11月, 2009 3 次提交
    • N
      md/raid5: Allow dirty-degraded arrays to be assembled when only party is degraded. · c148ffdc
      由 NeilBrown 提交于 
      Normally is it not safe to allow a raid5 that is both dirty and
degraded to be assembled without explicit request from that admin, as
it can cause hidden data corruption.
This is because 'dirty' means that the parity cannot be trusted, and
'degraded' means that the parity needs to be used.

However, if the device that is missing contains only parity, then
there is no issue and assembly can continue.
This particularly applies when a RAID5 is being converted to a RAID6
and there is an unclean shutdown while the conversion is happening.

So check for whether the degraded space only contains parity, and
in that case, allow the assembly.
Signed-off-by: NNeilBrown <neilb@suse.de>
      c148ffdc
    • N
      Don't unconditionally set in_sync on newly added device in raid5_reshape · 7ef90146
      由 NeilBrown 提交于 
      When a reshape finds that it can add spare devices into the array,
those devices might already be 'in_sync' if they are beyond the old
size of the array, or they might not if they are within the array.

The first case happens when we change an N-drive RAID5 to an
N+1-drive RAID5.
The second happens when we convert an N-drive RAID5 to an
N+1-drive RAID6.

So set the flag more carefully.
Also, ->recovery_offset is only meaningful when the flag is clear,
so only set it in that case.

This change needs the preceding two to ensure that the non-in_sync
device doesn't get evicted from the array when it is stopped, in the
case where v0.90 metadata is used.
Signed-off-by: NNeilBrown <neilb@suse.de>
      7ef90146
    • N
      md: allow v0.91 metadata to record devices as being active but not in-sync. · 0261cd9f
      由 NeilBrown 提交于 
      This is a combination that didn't really make sense before.
However when a reshape is converting e.g. raid5 -> raid6, the extra
device is not fully in-sync, but is certainly active and contains
important data.
So allow that start to be meaningful and in particular get
the 'recovery_offset' value (which is needed for any non-in-sync
active device) from the reshape_position.
Signed-off-by: NNeilBrown <neilb@suse.de>
      0261cd9f
  11. 12 11月, 2009 2 次提交
    • E
      sysctl drivers: Remove dead binary sysctl support · 894d2491
      由 Eric W. Biederman 提交于 
      Now that sys_sysctl is a wrapper around /proc/sys all of
the binary sysctl support elsewhere in the tree is
dead code.

Cc: Jens Axboe <axboe@kernel.dk>
Cc: Corey Minyard <minyard@acm.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Neil Brown <neilb@suse.de>
Cc: "James E.J. Bottomley" <James.Bottomley@suse.de>
Acked-by: Clemens Ladisch <clemens@ladisch.de> for drivers/char/hpet.c
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      894d2491
    • N
      md: factor out updating of 'recovery_offset'. · 5e865106
      由 NeilBrown 提交于 
      Each device has its own 'recovery_offset' showing how far
recovery has progressed on the device.
As the only real significance of this is that fact that it can
be stored in the metadata and recovered at restart, and as
only 1.x metadata can do this, we were only updating
'recovery_offset' to 'curr_resync_completed' when updating
v1.x metadata.
But this is wrong, and we will shortly make limited use of this
field in v0.90 metadata.

So move the update into common code.
Signed-off-by: NNeilBrown <neilb@suse.de>
      5e865106
  13. 09 11月, 2009 1 次提交
  15. 06 11月, 2009 2 次提交
    • N
      md/raid5: make sure curr_sync_completes is uptodate when reshape starts · 8dee7211
      由 NeilBrown 提交于 
      This value is visible through sysfs and is used by mdadm
when it manages a reshape (backing up data that is about to be
rearranged).  So it is important that it is always correct.
Current it does not get updated properly when a reshape
starts which can cause problems when assembling an array
that is in the middle of being reshaped.

This is suitable for 2.6.31.y stable kernels.

Cc: stable@kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>
      8dee7211
    • N
      md: don't clear endpoint for resync when resync is interrupted. · 24395a85
      由 NeilBrown 提交于 
      If a 'sync_max' has been set (via sysfs), it is wrong to clear it
until a resync (or reshape or recovery ...) actually reached that
point.
So if a resync is interrupted (e.g. by device failure),
leave 'resync_max' unchanged.

This is particularly important for 'reshape' operations that do not
change the size of the array.  For such operations mdadm needs to
monitor the reshape taking rolling backups of the section being
reshaped.  If resync_max gets cleared, the reshape can get ahead of
mdadm and then the backups that mdadm creates are useless.

This is suitable for 2.6.31.y stable kernels.
Cc: stable@kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>
      24395a85
  17. 20 10月, 2009 1 次提交
  19. 17 10月, 2009 1 次提交