On Sun, Jul 7, 2019 at 7:14 PM Xiao Ni <xni@xxxxxxxxxx> wrote:
>
> In 7471fb77(md/raid6: Fix anomily when recovering a single device in RAID6.) It avoids to re-read P
> when it can be computed from other members. But it misses the chance to re-write the right data
> to P. Now it sets R5_ReadError if the re-read fails. Because it avoids the re-read, so it misses
> the chance to set R5_ReadError. The re-write is submitted in state machine when r5dev has flag
> R5_ReadError. So it doesn't re-write the right data to disk. We need to do this to keep the raid
> having right data.
>
> Because it don't send re-read, so it also misses the chance to reset rdev->read_erros to 0. It can
> fail the disk when there are many read errors on P member disk(other disks don't have read error)
>
> V2: upper layer read request don't read parity/Q data. So there is no need to consider such situation.
> This is Reported-by: kbuild test robot <lkp@xxxxxxxxx>
>
> Fixes: 7471fb77(md/raid6: Fix anomily when recovering a single device in RAID6.)
> Signed-off-by: Xiao Ni <xni@xxxxxxxxxx>
The commit log should be 75 byte or narrower. checkpatch.pl should report this.
Applied with modified commit log (see below). Please let me know if anything is
not accurate.
Thanks,
Song
md/raid6: Set R5_ReadError when there is read failure on parity disk
7471fb77ce4d ("md/raid6: Fix anomily when recovering a single device in
RAID6.") avoids rereading P when it can be computed from other members.
However, this misses the chance to re-write the right data to P. This
patch sets R5_ReadError if the re-read fails.
Also, when re-read is skipped, we also missed the chance to reset
rdev->read_errors to 0. It can fail the disk when there are many read
errors on P member disk (other disks don't have read error)
V2: upper layer read request don't read parity/Q data. So there is no
need to consider such situation.
This is Reported-by: kbuild test robot <lkp@xxxxxxxxx>
Fixes: 7471fb77ce4d ("md/raid6: Fix anomily when recovering a single
device in RAID6.")
Cc: <stable@xxxxxxxxxxxxxxx> #4.4+
Signed-off-by: Xiao Ni <xni@xxxxxxxxxx>
Signed-off-by: Song Liu <songliubraving@xxxxxx>
