In looking through the error handler, if a command times out and is
added to the eh_cmd_q for the shost, the error handler is only awakened
once shost->host_busy (total number of i/os posted to the shost) is
equal to shost->host_failed (number of i/o that have been failed and put
on the eh_cmd_q). Which means, any other i/o that was outstanding must
either complete or have their timeout fire. Additionally, as all
further i/o is held off at the block layer as the shost is in recovery,
new i/o cannot be submitted until the error handler runs and resolves
the errored i/os.
Is this true ?
I take it is also true that the midlayer thus expects every i/o to have
an i/o timeout. True ?
The crux of this point is that when the recovery thread runs to aborts
the timed out i/os, is at the mercy of the last command to complete or
timeout. Additionally, as all further i/o is held off at the block layer
as the shost is in recovery, new i/o cannot be submitted until the error
handler runs and resolves the errored i/os. So all I/O on the host is
stopped until that last i/o completes/times out. The timeouts may be
eons later. Consider SCSI format commands or verify commands that can
take hours to complete.
Specifically, I'm in a situation currently, where an application is
using sg to send a command to a target. The app selected no-timeout - by
setting timeout to MAX_INT. Effectively it's so large its infinite.
This I/O was one of those "lost" on the storage fabric. There was
another command that long ago timed out and is sitting on the error
handlers queue. But nothing is happening - new i/o, or error handler to
resolve the failed i/o, until that inifinite i/o completes.
I'm hoping I hear that I just misunderstand things. If not, is there a
suggestion for how to resolve this predicament ? IMHO, I'm surprised
we stop all i/o for error handling, and that it can be so long later...
I would assume there's a minimum bound we would wait in the error
handler (30s?) before we unconditionally run it and abort anything that
was outstanding.
-- james s
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
