linux-stable.git/drivers/md/raid5.c, branch v3.3.7

md/raid5: Fix a bug about judging if the operation is syncing or replacing

2012-05-07T15:53:36+00:00

commit c6d2e084c7411f61f2b446d94989e5aaf9879b0f upstream.

When create a raid5 using assume-clean and echo check or repair to
sync_action.Then component disks did not operated IO but the raid
check/resync faster than normal.
Because the judgement in function analyse_stripe():
		if (do_recovery ||
		    sh->sector >= conf->mddev->recovery_cp)
			s->syncing = 1;
		else
			s->replacing = 1;
When check or repair,the recovery_cp == MaxSectore,so syncing equal zero
not one.

This bug was introduced by commit 9a3e1101b827
    md/raid5:  detect and handle replacements during recovery.
so this patch is suitable for 3.3-stable.

Signed-off-by: majianpeng 
Signed-off-by: NeilBrown 
Cc: Jes Sorensen 
Signed-off-by: Greg Kroah-Hartman

md/raid5: Mark device want_replacement when we see a write error.

2011-12-22T23:17:54+00:00

Now that WantReplacement drives are replaced cleanly, mark a drive
as WantReplacement when we see a write error.  It might get failed soon so
the WantReplacement flag is irrelevant, but if the write error is recorded
in the bad block log, we still want to activate any spare that might
be available.

Reviewed-by: Dan Williams 
Signed-off-by:  NeilBrown

md/raid5: If there is a spare and a want_replacement device, start replacement.

2011-12-22T23:17:53+00:00

When attempting to add a spare to a RAID[456] array, also consider
adding it as a replacement for a want_replacement device.

This requires that common md code attempt hot_add even when the array
is not formally degraded.

Reviewed-by: Dan Williams 
Signed-off-by: NeilBrown

md/raid5: recognise replacements when assembling array.

2011-12-22T23:17:53+00:00

If a Replacement is seen, file it as such.

If we see two replacements (or two normal devices) for the one slot,
abort.

Reviewed-by: Dan Williams 
Signed-off-by: NeilBrown

md/raid5: handle activation of replacement device when recovery completes.

2011-12-22T23:17:53+00:00

When recovery completes - as reported by a call to ->spare_active,
we clear In_sync on the original and set it on the replacement.

Then when the original gets removed we move the replacement from
'replacement' to 'rdev'.

This could race with other code that is looking at these pointers,
so we use memory barriers and careful ordering to ensure that
a reader might see one device twice, but never no devices.
Then the readers guard against using both devices, which could
only happen when writing.

Signed-off-by: NeilBrown

md/raid5: detect and handle replacements during recovery.

2011-12-22T23:17:53+00:00

During recovery we want to write to the replacement but not
the original.  So we have two new flags
 - R5_NeedReplace if this stripe has a replacement that needs to
   be written at some stage
 - R5_WantReplace if NeedReplace, and the data is available, and
   a 'sync' has been requested on this stripe.

We also distinguish between 'sync and replace' which need to read
all other devices, and 'replace' which only needs to read the
devices being replaced.

Note that during resync we always write to any replacement device.
It might not need to be written to, but as we don't read to compare,
we have to write to be sure.

Signed-off-by: NeilBrown

md/raid5: writes should get directed to replacement as well as original.

2011-12-22T23:17:53+00:00

When writing, we need to submit two writes, one to the original, and
one to the replacement - if there is a replacement.

If the write to the replacement results in a write error, we just fail
the device.  We only try to record write errors to the original.

When writing for recovery, we shouldn't write to the original.  This
will be addressed in a subsequent patch that generally addresses
recovery.

Reviewed-by: Dan Williams 
Signed-off-by: NeilBrown

md/raid5: allow removal for failed replacement devices.

2011-12-22T23:17:52+00:00

Enhance raid5_remove_disk to be able to remove ->replacement
as well as ->rdev.

Reviewed-by: Dan Williams 
Signed-off-by: NeilBrown

md/raid5: preferentially read from replacement device if possible.

2011-12-22T23:17:52+00:00

If a replacement device is present and has been recovered far enough,
then use it for reading into the stripe cache.

If we get an error we don't try to repair it, we just fail the device.
A replacement device that gives errors does not sound sensible.

This requires removing the setting of R5_ReadError when we get
a read error during a read that bypasses the cache.  It was probably
a bad idea anyway as we don't know that every block in the read
caused an error, and it could cause ReadError to be set for the
replacement device, which is bad.

Signed-off-by: NeilBrown

md/raid5: remove redundant bio initialisations.

2011-12-22T23:17:52+00:00

We current initialise some fields of a bio when preparing a
stripe_head, and again just before submitting the request.

Remove the duplication by only setting the fields that lower level
devices don't touch in raid5_build_block, and only set the changeable
fields in ops_run_io.

Reviewed-by: Dan Williams 
Signed-off-by: NeilBrown