Re: fc_remote_port_delete and returning SCSI commands from LLD

Christof Schmitt
2009-10-28T14:27:33Z

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