Mike Christie wrote:
> Hannes Reinecke wrote:
>> /*
>> + * Evaluate scsi return code
>> + */
>> +static int eval_scsi_error(int result, char *sense, int sense_len)
>> +{
>> + struct scsi_sense_hdr sshdr;
>> + int r = DM_ENDIO_REQUEUE;
>> +
>> + if (host_byte(result) != DID_OK)
>
>
> For values like DID_NO_CONNECT or DID_TRANSPORT FAILFAST, I think it
> makes sense to fail the path. Not in this patch, but a new one, would we
> want to modify dm-mpath so that we do not fail the path for errors like
> DID_ABORT or DID_SOFT_ERROR, DID_RESET or DID_ERROR?
Yeah, well, this patch was made to model the existing behaviour closely
so as the patch submission was not blocked by irrelevant side discussions ...
But yes, of course we should be a bit more selective on how to respond
to the various error codes. But this requires some more discussion with
the various vendors as things like 'DID_ERROR' have different meanings
for different HBAs ...
But this should be done once we agreed on the principle, ie on _how_
to pass the error codes up the the multipathing layer.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, 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
