md/raid1,raid10: always abort recover on write error.
authorNeilBrown <neilb@suse.de>
Thu, 31 Jul 2014 00:16:29 +0000 (10:16 +1000)
committerBen Hutchings <ben@decadent.org.uk>
Sat, 13 Sep 2014 22:41:40 +0000 (23:41 +0100)
commit9a28f9e6ec28037666ce0c0fb55165a05c8d01f0
treead8d0684f3f36f37ba592dc4645d212962d6e597
parent74eb879f487aa303b59e8da4c072bf7cf5526220
md/raid1,raid10: always abort recover on write error.

commit 2446dba03f9dabe0b477a126cbeb377854785b47 upstream.

Currently we don't abort recovery on a write error if the write error
to the recovering device was triggerd by normal IO (as opposed to
recovery IO).

This means that for one bitmap region, the recovery might write to the
recovering device for a few sectors, then not bother for subsequent
sectors (as it never writes to failed devices).  In this case
the bitmap bit will be cleared, but it really shouldn't.

The result is that if the recovering device fails and is then re-added
(after fixing whatever hardware problem triggerred the failure),
the second recovery won't redo the region it was in the middle of,
so some of the device will not be recovered properly.

If we abort the recovery, the region being processes will be cancelled
(bit not cleared) and the whole region will be retried.

As the bug can result in data corruption the patch is suitable for
-stable.  For kernels prior to 3.11 there is a conflict in raid10.c
which will require care.

Original-from: jiao hui <jiaohui@bwstor.com.cn>
Reported-and-tested-by: jiao hui <jiaohui@bwstor.com.cn>
Signed-off-by: NeilBrown <neilb@suse.de>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
drivers/md/raid1.c
drivers/md/raid10.c