RE: Question on SCSI target scan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2013-11-21 at 17:37 +0000, Elliott, Robert (Server Storage)
wrote:
> 
> > -----Original Message-----
> > From: Ewan Milne [mailto:emilne@xxxxxxxxxx]
> > Sent: Monday, 18 November, 2013 11:29 AM
> > To: Elliott, Robert (Server Storage)
> > Cc: Ramesh Chikkanayakanahally; linux-scsi@xxxxxxxxxxxxxxx;
> > jbottomley@xxxxxxxxxxxxx
> > Subject: RE: Question on SCSI target scan
> > 
> > On Fri, 2013-11-15 at 23:53 +0000, Elliott, Robert (Server Storage)
> > wrote:
> > > Beware that just because the LUN inventory is the same doesn't mean
> > > the logical units are the same.  A logical unit at LUN X might have been
> > > deleted and another logical unit created and assigned to LUN X, but
> > > now containing different content.  You need to check the logical unit
> > > name (in the Device Identification VPD page) too.
> > > ---
> > > Rob Elliott    HP Server Storage
> > >
> > 
> > If the properties of the volume behind a particular LUN are changed,
> > shouldn't something like ASC/ASCQ 3F 03 INQUIRY DATA HAS CHANGED,
> > 3F 04 DEVICE IDENTIFIER CHANGED be reported?  Or can we not expect
> > this if a LUN is removed and then re-added without an intervening
> > REPORT LUNS command?  (In that case, the REPORT LUNS data returned
> > will be no different.)
> > 
> > -Ewan
> > 
> 
> It might report that, and/or these:
> VOLUME SET CREATED OR MODIFIED (3Fh/0Ah)
> NOT READY TO READY CHANGE, MEDIUM MAY HAVE CHANGED (28h/00h)
> 
> However, the device server in the new logical unit might not know that 
> there was a previous logical unit assigned to that LUN and might not know 
> all the INQUIRY data, mode page values, log page values, etc. values that 
> were in use to compare them to the current values, so is probably unable 
> to report the specifics of what changed.  It will probably just report an 
> additional sense code with ASC=29h like POWER ON OCCURRED (29h/01h).  
> 
> Per the unit attention condition precedence level rules (see SAM-5
> revision 15 table 53), the additional sense codes with ASC=29h imply that 
> all other unit attention conditions might also have happened (INQUIRY 
> data changed, mode pages changed, log pages changed, capacity
> changed, etc.).  Software is supposed to assume the worst and check 
> everything again.  I'm not confident that much software really does that, 
> though.
> 
> The unit attention condition precedence is:
> 1. POWER ON, RESET, OR BUS DEVICE RESET OCCURRED (29h/00h)
> 2. POWER ON OCCURRED  (29h/01h) or 
>    DEVICE INTERNAL RESET  (29h/04h)
> 3. SCSI BUS RESET OCCURRED  (29h/02h) or 
>    MICROCODE HAS BEEN CHANGED  (3Fh/01h) or 
>    protocol specific (e.g., TRANSCEIVER MODE CHANGED
>    TO LVD 29h/06h in parallel SCSI)
> 4. BUS DEVICE RESET FUNCTION OCCURRED (29h/03h)
> 5. I_T NEXUS LOSS OCCURRED (29h/07h)
> 6. COMMANDS CLEARED BY POWER LOSS NOTIFICATION (2Fh/01h)
> 7. All others
> 
> Also, for each ASC value, ASCQ=00h has precedence over all ASCQ values
> that are nonzero. For example, PARAMETERS CHANGED (2Ah/00h) implies 
> that all the other 2Ah/xxh codes might have happened.
> 
> ---
> Rob Elliott    HP Server Storage

Useful information, thanks for the reply.

-Ewan


--
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux