Doug Ledford <[EMAIL PROTECTED]> writes:
> On Sun, 2007-10-28 at 01:27 -0500, Alberto Alonso wrote:
>> Even if the default timeout was really long (ie. 1 minute) and then
>> configurable on a per device (or class) via /proc it would really help.
>
> It's a band-aid. It's working around other bugs in the kernel instead
> of fixing the real problem.
Checks and balances.
Don't trust anyone.
Also some things are broken in hardware. I have external raid boxes
connected via scsi but when I just power-down one of the boxes it
never gives an I/O error or timeout. It seems to just hang. Should I
start fixing the scsi controler firmware to give errors?
A general timeout in the md layer would fix the problems independent
of what controler card I use. A real nifty band-aid. Call it a saftey
blanket.
>> > Generally speaking, most modern drivers will work well. It's easier to
>> > maintain a list of known bad drivers than known good drivers.
>>
>> That's what has been so frustrating. The old PATA IDE hardware always
>> worked and the new stuff is what has crashed.
>
> In all fairness, the SATA core is still relatively young. IDE was
> around for eons, where as Jeff started the SATA code just a few years
> back. In that time I know he's had to deal with both software bugs and
> hardware bugs that would lock a SATA port up solid with no return. What
> it sounds like to me is you found some of those.
There will always be bugs. I've seen scsi crash on error often enough
due to totaly broken drivers. You always run into that one odd race
condition the author never thought about when it really counts [MURPHY].
MfG
Goswin
-
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
