On 05/27/2013 12:44 AM, James Bottomley wrote: > > On Thu, 2013-05-23 at 11:14 -0700, Roland Dreier wrote: >> At LSF this year, we had a discussion about error handling and in >> particular the problem that SCSI midlayer error handling waits for the >> entire SCSI host (HBA) to quiesce before it starts to abort commands >> etc. >> >> James made the suggestion that FC should handle things the way SAS >> does, because SAS has a strategy handler that does things the right >> way. However, now that I finally sit down and look at the code, I >> don't see how this is the case. It seems inherent in the way that >> scsi_eh_scmd_add() and the thread in scsi_error_handler() work (in >> particular the strategy handler can't even be called until host_failed >> == host_busy; we don't bump host_failed without SHOST_RECOVERY set, >> which stops queueing commands to any devices attached to the whole >> HBA). >> >> James, am I understanding your suggestion properly? If so can you >> explain what you meant about the libsas code -- I see that it has its >> own strategy handler but as I said before we've already stopped every >> device attached to the HBA before we ever get there. > > It is, but I checked: Apparently it's not implemented in the sas > transport class. The original discussion when libsas was constructed, > as I remember it, was about using the scsi timeout handler to implement > a running abort. The idea is fairly simple: you use the first fire of > eh_timed_out to trigger the abort (or LUN reset) while simultaneously > returning BLK_EH_RESET_TIMER. If the timer fires again and the abort > hasn't returned, you escalate, otherwise you resend the command when the > abort returns. This allows you to handle single command failures (up to > LUN reset) without stopping the host. Obviously, if you have to > escalate to device reset, then you need to start the eh thread. > There are some problems with that: - Returning BLK_EH_RESET_TIMER will restart the timer with the _default_ blk timeout. Whereas the _abort_ timeout might (and, for some LLDDs, it definitely is) different from that. - Leaving the command running while abort is active will inevitably risk a double completion on the original command; the command abort might terminate the command at the same time as the (real) completion comes in. 'Normal' command timeouts are protected against this via REQ_ATOM_COMPLETE; commands aborted via scsi_finish_cmnd() are not. - LLDDs typically won't return a command status even for a command which has been aborted via ABORT TASK TMF. So the midlayer probably will never get notified if the command got aborted via ABORT TASK. Especially the last point made me abandon this idea for my EH rewrite. We would be having a real benefit if we somehow could get the command status _from the target_ for an aborted command. But as it appears we won't. So as any status is made up anyway I'd very much prefer to have it set by the midlayer. Which renders the whole operation quite pointless and we're better off using the existing syntax for command aborts. Plus it makes life _so much_ easier for the implementation ... But to answer Roland: Have you checked my patchset? It should help for command timeouts ... Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
