]> git.baikalelectronics.ru Git - kernel.git/commit
raid1: prefer disk without bad blocks
authorTomasz Majchrzak <tomasz.majchrzak@intel.com>
Fri, 12 May 2017 12:26:10 +0000 (14:26 +0200)
committerShaohua Li <shli@fb.com>
Fri, 12 May 2017 21:41:15 +0000 (14:41 -0700)
commitc21588be7046bb3d7bd091ae876732b52e04ef6e
tree4ddf83040aee745295f9ae92d628191b74e34bf8
parent18e9ba616c21cbc0a9e8c2ee1a7e67d925f9e956
raid1: prefer disk without bad blocks

If an array consists of two drives and the first drive has the bad
block, the read request to the region overlapping the bad block chooses
the same disk (with bad block) as device to read from over and over and
the request gets stuck. If the first disk only partially overlaps with
bad block, it becomes a candidate ("best disk") for shorter range of
sectors. The second disk is capable of reading the entire requested
range and it is updated accordingly, however it is not recorded as a
best device for the request. In the end the request is sent to the first
disk to read entire range of sectors. It fails and is re-tried in a
moment but with the same outcome.

Actually it is quite likely scenario but it had little exposure in my
test until commit 715d40b93b10 ("md/raid1: add failfast handling for
reads.") removed preference for idle disk. Such scenario had been
passing as second disk was always chosen when idle.

Reset a candidate ("best disk") to read from if disk can read entire
range. Do it only if other disk has already been chosen as a candidate
for a smaller range. The head position / disk type logic will select
the best disk to read from - it is fine as disk with bad block won't be
considered for it.

Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
Signed-off-by: Shaohua Li <shli@fb.com>
drivers/md/raid1.c