On Tue, Oct 27, 2009 at 04:53:50PM -0500, Mike Christie wrote: > Christof Schmitt wrote: >> On Wed, Oct 21, 2009 at 01:11:15PM -0500, Mike Christie wrote: >>> Christof Schmitt wrote: >>>> If the remote_port status is not BLOCKED, this will trigger the SCSI >>>> midlayer error handling which cannot do much during the interruption >>>> to the hardware and will mark the SCSI devices 'offline'. In order to >>>> prevent this, the rule would be: First call fc_remote_port_delete to >>>> set the remote port (or in the case of an HBA interruption all remote >>>> ports) to BLOCKED, and only after this step call scsi_done to pass the >>>> SCSI commands back to the upper layers. >>>> >>> One other note when doing this. >>> >>> For problems where you are deleting the rport, it is best to use >>> something like DID_TRANSPORT_DISRUPTED to fail the cmd if you are >>> failing it right away. >> >> "something like DID_TRANSPORT_DISRUPTED" would be any error code that >> goes through "maybe_retry" in scsi_decide_disposition? I guess moving >> to DID_TRANSPORT_DISRUPTED is nice for consistency, but DID_ERROR >> triggers the same code paths as far as i can see. > > It could be a little different. See scsi_noretry_cmd. If you used > DID_ERROR and something set the driver failfast bit then it would be > fast failed. Ok. Somehow i missed scsi_noretry_cmd while looking at the SCSI code. Then it makes sense to report DID_TRANSPORT_DISRUPTED from the zfcp. I will target the zfcp patch for the next merge window. Christof -- 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
