>-----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. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
