Re: fc_remote_port_delete and returning SCSI commands from LLD

[Christof Schmitt <christof.schmitt@de.ibm.com>]

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