@@ -3671,7 +3671,14 @@ handle_failed_stripe(struct r5conf *conf, struct stripe_head *sh,
sh->dev[i].sector + RAID5_STRIPE_SECTORS(conf)) {
struct bio *nextbi =
r5_next_bio(conf, bi, sh->dev[i].sector);
-
+ /* If we recorded bad blocks from the metadata
+ * on any of the devices then report this to
+ * userspace in case anyone might suspect
+ * something more fundamental instead
+ */
+ if (s->bad_blocks)
+ pr_warn_ratelimited("%s: read encountered block in device bad block list.",
+ mdname(conf->mddev));
bio_io_error(bi);
bi = nextbi;
}
@@ -4682,6 +4689,7 @@ static void analyse_stripe(struct stripe_head *sh, struct stripe_head_state *s)
if (rdev) {
is_bad = rdev_has_badblock(rdev, sh->sector,
RAID5_STRIPE_SECTORS(conf));
+ s->bad_blocks++;
if (s->blocked_rdev == NULL) {
if (is_bad < 0)
set_bit(BlockedBadBlocks, &rdev->flags);
@@ -282,7 +282,7 @@ struct stripe_head_state {
* read all devices, just the replacement targets.
*/
int syncing, expanding, expanded, replacing;
- int locked, uptodate, to_read, to_write, failed, written;
+ int locked, uptodate, to_read, to_write, failed, written, bad_blocks;
int to_fill, compute, req_compute, non_overwrite;
int injournal, just_cached;
int failed_num[2];
It's easy to suspect that there might be some underlying hardware failures or similar issues when userspace receives a Buffer I/O error from a raid device. In order to hopefully send more sysadmins on the right track, lets report that a read failed at least in part due to bad blocks in the bad block list on device metadata. There are real world examples where bad block lists accidentally get propagated or copied around, so having this warning helps mitigate the consequences Signed-off-by: Doug V Johnson <dougvj@dougvj.net> --- drivers/md/raid5.c | 10 +++++++++- drivers/md/raid5.h | 2 +- 2 files changed, 10 insertions(+), 2 deletions(-)