Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

md/raid1: don't abort a resync on the first badblock.

commit b7219cc upstream.

If a resync of a RAID1 array with 2 devices finds a known bad block
one device it will neither read from, or write to, that device for
this block offset.
So there will be one read_target (The other device) and zero write
This condition causes md/raid1 to abort the resync assuming that it
has finished - without known bad blocks this would be true.

When there are no write targets because of the presence of bad blocks
we should only skip over the area covered by the bad block.
RAID10 already gets this right, raid1 doesn't.  Or didn't.

As this can cause a 'sync' to abort early and appear to have succeeded
it could lead to some data corruption, so it suitable for -stable.

Reported-by: Alexander Lyakas <>
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
  • Loading branch information...
commit 898ece8e5e5102c627f8f2ef26d281f71b439169 1 parent 1c88c58
@neilbrown neilbrown authored Ben Hutchings committed
Showing with 4 additions and 1 deletion.
  1. +4 −1 drivers/md/raid1.c
5 drivers/md/raid1.c
@@ -2321,7 +2321,10 @@ static sector_t sync_request(struct mddev *mddev, sector_t sector_nr, int *skipp
/* There is nowhere to write, so all non-sync
* drives must be failed - so we are finished
- sector_t rv = max_sector - sector_nr;
+ sector_t rv;
+ if (min_bad > 0)
+ max_sector = sector_nr + min_bad;
+ rv = max_sector - sector_nr;
*skipped = 1;
return rv;
Please sign in to comment.
Something went wrong with that request. Please try again.