linux-stable.git/drivers/md/raid1.c, branch linux-2.6.33.y

md/raid1: really fix recovery looping when single good device fails.

2011-03-21T19:43:51+00:00

commit 8f9e0ee38f75d4740daa9e42c8af628d33d19a02 upstream.

Commit 4044ba58dd15cb01797c4fd034f39ef4a75f7cc3 supposedly fixed a
problem where if a raid1 with just one good device gets a read-error
during recovery, the recovery would abort and immediately restart in
an infinite loop.

However it depended on raid1_remove_disk removing the spare device
from the array.  But that does not happen in this case.  So add a test
so that in the 'recovery_disabled' case, the device will be removed.

This suitable for any kernel since 2.6.29 which is when
recovery_disabled was introduced.

Reported-by: Sebastian Färber 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: Fix read balancing in RAID1 and RAID10 on drives > 2TB

2010-07-05T18:15:49+00:00

commit af3a2cd6b8a479345786e7fe5e199ad2f6240e56 upstream.

read_balance uses a "unsigned long" for a sector number which
will get truncated beyond 2TB.
This will cause read-balancing to be non-optimal, and can cause
data to be read from the 'wrong' branch during a resync.  This has a
very small chance of returning wrong data.

Reported-by: Jordan Russell 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid1: fix counting of write targets.

2010-07-05T18:15:49+00:00

commit 964147d5c86d63be79b442c30f3783d49860c078 upstream.

There is a very small race window when writing to a
RAID1 such that if a device is marked faulty at exactly the wrong
time, the write-in-progress will not be sent to the device,
but the bitmap (if present) will be updated to say that
the write was sent.

Then if the device turned out to still be usable as was re-added
to the array, the bitmap-based-resync would skip resyncing that
block, possibly leading to corruption.  This would only be a problem
if no further writes were issued to that area of the device (i.e.
that bitmap chunk).

Suitable for any pending -stable kernel.

Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: add MODULE_DESCRIPTION for all md related modules.

2009-12-14T01:51:41+00:00

Suggested by  Oren Held 

Signed-off-by: NeilBrown

md: move offset, daemon_sleep and chunksize out of bitmap structure

2009-12-14T01:51:41+00:00

... and into bitmap_info.  These are all configuration parameters
that need to be set before the bitmap is created.

Signed-off-by: NeilBrown

md/raid1: add takeover support for raid5->raid1

2009-12-14T01:51:41+00:00

A 2-device raid5 array can now be converted to raid1.

Signed-off-by: NeilBrown

md: add honouring of suspend_{lo,hi} to raid1.

2009-12-14T01:51:40+00:00

This will allow us to stop writeout to portions of the array
while  they are resynced by someone else - e.g. another node in
a cluster.

Signed-off-by: NeilBrown

md: revert incorrect fix for read error handling in raid1.

2009-12-01T06:30:59+00:00

commit 4706b349f 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 dd00a99e7a 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: NeilBrown 
Cc: stable@kernel.org

md: raid1/raid10: handle allocation errors during array setup.

2009-10-16T04:55:44+00:00

Both raid1 and raid10 create a mempool during startup.
If the 'alloc' function for this mempool fails, unplug_slaves
is called.
If that happens when the pool is being initialised, unplug_slaves
will try to use the 'conf' structure that isn't filled in yet, and
badness will happen.

So ensure that unplug_slaves doesn't get called unless we know
that the conf structure if fully initialised.

Signed-off-by: NeilBrown

md/raid1/raid10: add a cond_resched

2009-10-16T04:55:32+00:00

During 'check' of a raid1 or raid10 it is possible for the management
thread to spend a lot of time running 'memcmp' on blocks from
different devices, so make sure the thread has a chance to schedule.
raid5d already has a cond_resched (in process_stripe).

Reported-By: Lee Howard 
Signed-off-by: NeilBrown