On Wednesday September 5, [EMAIL PROTECTED] wrote:
I've been looking at ways to minimize the impact of a faulty drive in
a raid1 array. Our major problem is that a faulty drive can absorb
lots of wall clock time in error recovery within the device driver
(SATA libata error handler in this case), during which any further raid
activity is blocked and the system effectively hangs. This tends to
negate the high availability advantage of placing the file system on a
RAID array in the first place.
We've had one particularly bad drive, for example, which could sync
without indicating any write errors but as soon as it became active in
the array would start yielding read errors. It this particular case it
would take 30 minutes or more for the process to progress to a point
where some fatal error would occur to kick the drive out of the array
and return the system to normal opreation.
For SATA, this effect can be partially mitigated by reducing the default
30 second timeout at the SCSI layer (/sys/block/sda/device/timeout).
However, the system stills spends 45 seconds or so per retry in the
driver issuing various reset operations in an attempt to recover from
the error before returning control to the SCSI layer.
I've been experimenting with a patch which makes two basic changes.
1) It issues the first read request against a mirror with more than 1 drive
active using the BIO_RW_FAILFAST flag to short-circuit the SCSI layer from
re-trying the failed operation in the low level device driver the default 5
times.
I've recently become aware that we really need FAILFAST - possibly for
all IO from RAID1/5. Modern drives don't need any retry at the OS
level - if the retry in the firmware cannot get the data, nothing will.
2) It adds a threshold on the level of recent error acivity which is
acceptable in a given interval, all configured through /sys. If a
mirror has generated more errors in this interval than the threshold,
it is kicked out of the array.
This is probably a good idea. It bothers me a little to require 2
separate numbers in sysfs...
When we get a read error, we quiesce the device, the try to sort out
the read errors, so we effectively handle them in batches. Maybe we
should just set a number of seconds, and if there are a 3 or more
batches in that number of seconds, we kick the drive... just a thought.
One would think that #2 should not be necessary as the raid1 retry
logic already attempts to rewrite and then reread bad sectors and fails
the drive if it cannot do both. However, what we observe is that the
re-write step succeeds as does the re-read but the drive is really no
more healthy. Maybe the re-read is not actually going out to the media
in this case due to some caching effect?
I have occasionally wondered if a cache would defeat this test. I
wonder if we can push a FORCE MEDIA ACCESS flag down with that
read. I'll ask.
This patch (against 2.6.20) still contains some debugging printk's but
should be otherwise functional. I'd be interested in any feedback on
this specific approach and would also be happy if this served to foster
an error recovery discussion which came up with some even better approach.
Thanks. I agree that we do need something along these lines. It
might be a while before I can give the patch the brainspace it
deserves as I am travelling this fortnight.
NeilBrown
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
