Dev, Vasu wrote: >> -----Original Message----- >> From: Mike Christie [mailto:[EMAIL PROTECTED] >> Yeah, I am just saying if we have to add complexity to handle it it >> might not be worth it because at this point performance is hosed. If we >> were failing the IO with different errors codes to try and get it > failed >> over for multipath quickly that might be different. But if we can > simply >> check the reject response and reason and check what is going on with > the >> command, it should be fine (not complex) and I agree with you that we >> should do it for certain safe cases. >> > > I don't know those all certain safe cases but yes it will be a simple > change to check very few BA_RJT reason and explanations codes here for > safe cases. And I also don't know most likely those safe cases and their > typical frequency to assess worth of handling some of the BA_RJT codes > here v/s let always scsi-eh recover from such cases. > > However I think BA_RJT with FC_BA_RJT_NONE and FC_BA_RJT_LOG_ERR(with > FC_BA_RJT_INV_XID) will be most common safe case in poor quality lossy > link to complete exch here in FCP to avoid lengthy scsi-eh in this case > to all the way to lun reset as you described earlier in this email as > per current code state. I can complete exch here for only these cases > (FC_BA_RJT_NONE & FC_BA_RJT_LOG_ERR) since at least I see BA_RJT with > FC_BA_RJT_LOG_ERR and FC_BA_RJT_INV_XID quite often when a scsi response > is dropped to my target and FC_BA_RJT_NONE seem general case to assume > safe case here. I want to avoid lun reset for at least these cases as > per current code. >
Sounds good to me. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
