Jim Meyer wrote:
>
> Hello!
>
> I'm looking to understand fully what this means:
>
> Mar 14 06:44:34 pink kernel: md0: read error while reconstructing,
> at block 0(4096).
>
> This seems to be where my SW RAID5 array chokes.
>
> Thanks!
>
> --j
> --
> Jim Meyer, Geek At Large [EMAIL PROTECTED]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to [EMAIL PROTECTED]
I'm going to assume that this is an out-take from your earlier question.
Further, I've only been using a RAID set for a little while myself, but
I've had a few problems and dug somewhat deep into the code...
Starting with what you probably already know, when the RAID5 driver decides
to kick a drive out of the array because of an I/O error, it looks for a
spare and starts the reconstruction process. This involves reading ALL the
other blocks on all the other disks to reconstruct the blocks from the
failed disk and writing them to the spare. If there is an I/O error on the
spare disk, the reconstruction process stops with the message you saw.
If there are additional spares, they are supposed to be tried in turn.
I've had a similar problem except that the spare drive I had such severe
problems that it hung the SCSI bus and then the whole system. Needless
to say, I stopped using the spare.
I also noticed that you forced the array reconstruction. As the warning
says, this puts all your data at risk, and there is a safer way to
reconstruct the array. Try using the 'raidhotremove /dev/md0 /dev/sd?1'
command (with an appropriate replacement for the '?') and then add it
back in by changing 'remove' to 'add'.
However, I'm not too happy with the linux RAID5 implementation. In my
opinion, a number of changes need to be made, but I'm not sure how to
make them or get them accepted into the official distribution if I did
make the changes.
The changes I think should be made in order of priority are:
1) Read and write errors should be retried at least once before kicking
the drive out of the array.
2) On more persistent read errors, the failed block (or whatever unit is
represented by a buffer) should be reconstructed and the buffer marked
dirty so good data is written back to the disk.
3) Drives should not be kicked out of the array unless they are having
really persistent problems. I've an idea on how to define 'really
persistent' but it requires a bit of math to explain, so I'll only
go into it if someone is interested.
Then there is a couple changes that might improve recovery performance:
4) If the drive being kicked out is not totally inoperable and there is
a spare drive to replace it, try to copy the data from the failing
drive to the spare rather than reconstructing the data from all the
other disks. Fall back to full reconstruction if the error rate gets
too high.
5) When doing (4) use the SCSI 'copy' command if the drives are on the
same bus, and the host adapter and driver supports 'copy'. However,
this should be done with caution. 'copy' is not generally used and
any number of undetected firmware bugs might make it unreliable.
An additional category may need to be added to the device black list.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
