On 10/15/2013 05:32 AM, vaughan wrote: > On 10/14/2013 07:13 PM, Hannes Reinecke wrote: >> In the log, inquiry to LUN7 return a sense - asc,ascq=04h,0Ch >> (Logical unit not accessible, target port in unavailable state). >> And this is ignored, so scsi_probe_lun() returns -EIO and the scan >> process is aborted. >> >> I have two questions: >> 1. Is it correct for hardware to return a sense 04h,0Ch to inquiry >> again, even after presenting this lun in responce to REPORT_LUN >> command? >> Yes, this is correct. 'REPORT LUNS' is supported in 'Unavailable' state. >> >>> 2. Since windows and solaris can continue scan, is it reasonable for >>> linux to do the same, even for a fault-tolerance purpose? >>> >> Hmm. Yes, and no. >> >> _Actually_ this is an issue with the target, as it looks as if it >> will return the above sense code while sending an 'INQUIRY' to the >> device. >> SPC explicitely states that the INQUIRY command should _not_ fail >> for unavailable devices. > Hi all, > > I found this below in spc4. >>>> > 5.15.2.4.4 Target port group asymmetric access states - Standby state > While in the unavailable primary target port asymmetric access state, > the device server shall support those of > the following commands that it supports while in the active/optimized state: > a) INQUIRY (the peripheral qualifier (see 6.6.2) shall be set to 001b); > .... > For those commands that are not supported, the device server shall > terminate the command with CHECK > CONDITION status, with the sense key set to NOT READY, and the > additional sense code set to LOGICAL > UNIT NOT ACCESSIBLE, TARGET PORT IN UNAVAILABLE STATE. > <<< > From the above, I suppose the hardware may works very compliant with > spc. The case could be: > Storage is a alua supported target. Initiator sent REPORT_LUN to target, > target return all pqual=000b to it. > Then Initiator INQUIRY lun 7 which is in standby state where pqual=000b > not 001b. So this INQUIRY is regarded as > 'not supported', and get terminated with CHECK_CONDITION, sense key=NOT > READY, asc,ascq=04h,0ch. > > Could you confirm if my understanding is right or wrong? > Wrong. The sentence states that the device server _shall_ support those commands, where the results should be identical as if the port would have been in active/optimized state. So INQUIRY always has to be supported, regardless of which primary ALUA state the port happens to be in. (Otherwise we'd be hard-pressed to figure out whether the port is in 'unavailable' ALUA state in the first place, as without the INQUIRY data we couldn't even _tell_ if ALUA is supported.) So yeah, it really looks like a firmware issue here. But that notwithstanding, did you get a chance to test my patch? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, 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
