> * The current IO timeouts are too long. It's not like reducing this is > difficult. The only reason why we haven't reduced it yet is because we They are too short. > haven't been able to agree on what's the proper timeout value. > According to Mark, 8 secs should be fine (Windows uses it) for > read/writes but there seem to be some corner cases. The worst case I've seen on bad blocks is up over sixty seconds and as a result of our underlength timeouts we get continuous retries and mode changedowns in response to this not a proper error and raid failover. The worst case on cache flush is even longer! We have the same problem with CD devices. Now we should probably have a shorter timeout where we then check the status bits for BUSY so we can quickly catch lost interrupts or commands but that is quite different. > * Some rare controllers fail miserably after a timeout but this is > pretty rare and getting rarer. I don't think we need to consider this > the main deciding factor. Several require resets, the driver should be doing this work. Again the poll on timeout to check if we just lost the IRQ would improve this also but is only done by old IDE right now. > * Currently, the transfer speed setting reached by EH actions is not > persistent. On the next boot, the device would have to go through the > same thing all over again, which isn't too pleasant. It would be great > if we can make this setting persistent. Maybe this can be done libata > sysfs and udev? How ? you've no idea what device combination will appear next boot ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
