Re: RAID 5 recovery to not degrade device on bad block

Anshuman Aggarwal [off-list ref] writes:

Here is a simple feature request which I assume would not be much
logic change for kernel devs familiar with the code.

Essentially, if I understand correctly, the kernel raid code will try
to let the drive fix a bad sector and otherwise fail the device and
degrade the array.
However, if an array is already degraded then this behvaviour can be
very limiting because typically you are in recovery mode and want to
get as much data out to your new disk as you can.

I would say that for an already degraded array, bad blocks should
*NOT* by default cause a single bad block to fail the whole
array...instead just log the bad blocks to the syslog and let the
admin take care of it.

Big problem there.

As long as the raid is degrade a bad block can be reported to the
system as I/O error.

But consider what happens when you resync the drive and don't stop on
a bad block. The block on the new drive coresponding to the bad block
can not be initialized corectly. But a read of the bad block would
trigger the block to be recomputed from the remaining disks. Instead
of an I/O error you would get invalid data.

What would be needed is the ability to mark blocks as bad. Even with
bitmap support the bit cover too large an area.

Right now, the big benefit of RAID5 is being affected

Ideally, I'd like to see Neil's road map bad block device handler
implemented (have often thought of tinkering with the block device
code in the kernel to do just that)...but till then a simple check
that an array is  degraded before failing a device which would render
the whole array inoperable should suffice? This could throw big errors
in the syslog but at least the a 2 TB MD array won't be down because
of 1 512 byte sector?

Thanks,
Anshuman

MfG
        Goswin