On 2/2/07, Mark Lord <liml@xxxxxx> wrote:
7 seconds is not enough for current drives to report back. Adding another (8 seconds total) is enough, but I prefer to see a little margin there, so call it 10 seconds.
If you're going to allow 30 seconds (or more) for a cache flush, you probably want to allow 30 seconds (or more) for any command that might implicitly cause a cache flush. Things like EXECUTE DEVICE DIAGNOSTICS, IDENTIFY DEVICE, NOP, STANDBY/IDLE IMMEDIATE, both "soft" and "hard" reset, most SMART commands, etc. In fact, my understanding is that many devices will flush their write caches to disk when receiving non-data commands, so those commands may take a while if they occur immediately following heavy write activity, even without errors being present. While sure, a reset should function fine being issued in the middle of a command, and bring the drive back to a ready state, I don't know if these assumptions about 7s vs 8s vs 10s are always going to be valid for disk drives purchased through distribution channels or in the generic PC market, as opposed to "RAID edition" or "MaxLine" or similar branding from other vendors, where the firmware may have been specifically optimized for quicker command completion, quicker status reporting and less exhaustive error recovery. Many linux users I assume are buying/borrowing/stealing cheap old gear from whatever source they can, and I don't want to unnecessarilly risk compounding the issue in their environments. --eric - 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
