Re: error handler scheduling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13-03-26 10:11 PM, James Smart wrote:
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,
After many encounters with the Linux SCSI mid-level error
handler I have concluded it is uncontrollable and
seemingly random, seen from the user space. Interestingly,
several attempts to add finer grained controls over
lu/target/host resets have been rebuffed.

So my policy is to avoid timeout induced resets (like the
plague). Hence the default with sg_format is to set the IMMED
bit and use TEST UNIT READY or REQUEST SENSE polling to
monitor progress **. With commands like VERIFY, send many
reasonably sized commands, not one big one. And a special
mention for the SCSI WRITE SAME command which probably
has T10's silliest definition: if the NUMBER OF
LOGICAL BLOCKS field is set to zero it means keep writing
until the end of the disk *** and that might be 20 hours
later! The equivalent field set to zero in a SCSI VERIFY
or WRITE *** command means do nothing.

Doug Gilbert


**   You can still run into problems when a SCSI FORMAT UNIT
     with the IMMED bit set: some other kernel subsystem or
     user space program may decide to send a SCSI command to the
     disk during format. Then said code may not comprehend why
     the disk in question is not ready and ends up triggering
     mid-level error handling which blows the format out of
     the water. That leaves the disk in the "format corrupt"
     state.

***  recently the Block Limits VPD has (knee-)capped this
     with the WSNZ bit

**** apart from the obsolete WRITE(6) command which found
     another non obvious interpretation for a zero transfer
     length
--
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux