Question on SCSI target scan

Question on SCSI target scan

[Ramesh Chikkanayakanahally]

Hi,

This question is related to scsi_transport_fc layer.

Background:
    When new LUNs are added to a target, the target can send check condition with SK/ASC/ASCQ indicating that the reported LUNS data has changed. Then the initiator can send the report LUNs command to discover the changes. But if there are currently no LUNs or in case there is no activity on existing LUNs, then this mechanism will not be efficient. So few target implementations seem to trigger RSCN with the Event qualifier set to zeroes (event not specified) and Address format set to Port address of the effected target port. The expectation here is that, if the initiator had already logged into this target, it would verify the status of this target and if found online, it would issue report LUNs to discover the changes to LUNs. While this mechanism does not comply with SCSI or FC standards, this looks like one of the methods that is used by few target implementations. Assumption here is that, there is no other mechanism provided by SCSI or FC standards to achieve this.

Question:
  The existing interfaces of scsi_transport_fc module does not seem to provide a mechanism to trigger the SCSI target scan on a rport which is already registered using fc_remote_port_add() and is currently online (not blocked or deleted). If this understanding is correct, would it be useful to provide an interface that can be used to trigger the SCSI target scan in the above mentioned scenario ?

Could you please suggest ?

Thanks,
Ramesh C N

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Question on SCSI target scan

[Elliott, Robert (Server Storage)]

That sounds similar to Broadcast (Asynchronous Event) in Serial Attached 
SCSI (SAS), which is defined as:
    "Originated by an SSP target port when an event occurs (e.g., a hard
    reset) that causes one or more unit attention conditions to be established
    for one or more logical units accessible through the SSP target port."

The SCSI architecture model neither mandates nor precludes SCSI transport 
protocols from defining such a mechanism.  FCP-4 (SCSI over Fibre Channel)
doesn't mention using RSCN for that purpose, but it sounds like a
reasonable approach.

In SAS, there is no indication which SCSI target ports or logical unit(s) sent 
the Broadcast, so sending the QUERY ASYNCHRONOUS EVENT task 
management function to each logical unit is the quickest way to find them.
Since Fibre Channel's RSCN only identifies the SCSI target port, you still 
need to check all the logical units.

For each logical unit found with a pending unit attention condition, send
a command on which unit attention conditions are reported (a command 
other than INQUIRY and REPORT LUNS).  REQUEST SENSE is a good choice; 
it'll return GOOD status, return the unit attention condition as the 
parameter data, and clear the unit attention condition.  Repeat sending
REQUEST SENSE until all the unit attention conditions have been reported; 
there could be several queued up.

The additional sense code advises what to do next.  REPORTED LUNS 
DATA HAS CHANGED means sending REPORT LUNS is appropriate.

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


> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Ramesh Chikkanayakanahally
> Sent: Wednesday, 06 November, 2013 8:10 AM
> To: linux-scsi@vger.kernel.org
> Cc: jbottomley@parallels.com
> Subject: Question on SCSI target scan
> 
> Hi,
> 
> This question is related to scsi_transport_fc layer.
> 
> Background:
>     When new LUNs are added to a target, the target can send check condition
> with SK/ASC/ASCQ indicating that the reported LUNS data has changed. Then
> the initiator can send the report LUNs command to discover the changes. But
> if there are currently no LUNs or in case there is no activity on existing LUNs,
> then this mechanism will not be efficient. So few target implementations
> seem to trigger RSCN with the Event qualifier set to zeroes (event not
> specified) and Address format set to Port address of the effected target
> port. The expectation here is that, if the initiator had already logged into this
> target, it would verify the status of this target and if found online, it would
> issue report LUNs to discover the changes to LUNs. While this mechanism
> does not comply with SCSI or FC standards, this looks like one of the methods
> that is used by few target implementations. Assumption here is that, there is
> no other mechanism provided by SCSI or FC standards to achieve this.
> 
> Question:
>   The existing interfaces of scsi_transport_fc module does not seem to
> provide a mechanism to trigger the SCSI target scan on a rport which is
> already registered using fc_remote_port_add() and is currently online (not
> blocked or deleted). If this understanding is correct, would it be useful to
> provide an interface that can be used to trigger the SCSI target scan in the
> above mentioned scenario ?
> 
> Could you please suggest ?
> 
> Thanks,
> Ramesh C N
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Question on SCSI target scan

[Ramesh Chikkanayakanahally]

Thanks for the response. 

If using RSCN sounds like a reasonable approach in this scenario (protocol limitations),  then as per the original question  - would it be acceptable to add an interface in scsi_transport_fc layer, which can be invoked on receiving RSCN to trigger SCSI target re-scan (REPORT LUNS) ?

Thanks,
Ramesh C N

-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com] 
Sent: Saturday, November 16, 2013 5:23 AM
To: Ramesh Chikkanayakanahally; linux-scsi@vger.kernel.org
Cc: jbottomley@parallels.com
Subject: RE: Question on SCSI target scan

That sounds similar to Broadcast (Asynchronous Event) in Serial Attached SCSI (SAS), which is defined as:
    "Originated by an SSP target port when an event occurs (e.g., a hard
    reset) that causes one or more unit attention conditions to be established
    for one or more logical units accessible through the SSP target port."

The SCSI architecture model neither mandates nor precludes SCSI transport protocols from defining such a mechanism.  FCP-4 (SCSI over Fibre Channel) doesn't mention using RSCN for that purpose, but it sounds like a reasonable approach.

In SAS, there is no indication which SCSI target ports or logical unit(s) sent the Broadcast, so sending the QUERY ASYNCHRONOUS EVENT task management function to each logical unit is the quickest way to find them.
Since Fibre Channel's RSCN only identifies the SCSI target port, you still need to check all the logical units.

For each logical unit found with a pending unit attention condition, send a command on which unit attention conditions are reported (a command other than INQUIRY and REPORT LUNS).  REQUEST SENSE is a good choice; it'll return GOOD status, return the unit attention condition as the parameter data, and clear the unit attention condition.  Repeat sending REQUEST SENSE until all the unit attention conditions have been reported; there could be several queued up.

The additional sense code advises what to do next.  REPORTED LUNS DATA HAS CHANGED means sending REPORT LUNS is appropriate.

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


> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Ramesh Chikkanayakanahally
> Sent: Wednesday, 06 November, 2013 8:10 AM
> To: linux-scsi@vger.kernel.org
> Cc: jbottomley@parallels.com
> Subject: Question on SCSI target scan
> 
> Hi,
> 
> This question is related to scsi_transport_fc layer.
> 
> Background:
>     When new LUNs are added to a target, the target can send check condition
> with SK/ASC/ASCQ indicating that the reported LUNS data has changed. Then
> the initiator can send the report LUNs command to discover the changes. But
> if there are currently no LUNs or in case there is no activity on existing LUNs,
> then this mechanism will not be efficient. So few target implementations
> seem to trigger RSCN with the Event qualifier set to zeroes (event not
> specified) and Address format set to Port address of the effected target
> port. The expectation here is that, if the initiator had already logged into this
> target, it would verify the status of this target and if found online, it would
> issue report LUNs to discover the changes to LUNs. While this mechanism
> does not comply with SCSI or FC standards, this looks like one of the methods
> that is used by few target implementations. Assumption here is that, there is
> no other mechanism provided by SCSI or FC standards to achieve this.
> 
> Question:
>   The existing interfaces of scsi_transport_fc module does not seem to
> provide a mechanism to trigger the SCSI target scan on a rport which is
> already registered using fc_remote_port_add() and is currently online (not
> blocked or deleted). If this understanding is correct, would it be useful to
> provide an interface that can be used to trigger the SCSI target scan in the
> above mentioned scenario ?
> 
> Could you please suggest ?
> 
> Thanks,
> Ramesh C N
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question on SCSI target scan

[James Bottomley]

On Mon, 2013-11-18 at 00:52 -0700, Ramesh Chikkanayakanahally wrote:
> Thanks for the response. 
> 
> If using RSCN sounds like a reasonable approach in this scenario
> (protocol limitations),  then as per the original question  - would it
> be acceptable to add an interface in scsi_transport_fc layer, which
> can be invoked on receiving RSCN to trigger SCSI target re-scan
> (REPORT LUNS) ?

No, but what you want to do is send a TEST UNIT READY to one of the
target LUNs ... you can trigger that from the FC transport class, I
think.  That should return a CHECK CONDITION/UNIT ATTENTION which will
trigger the collection of sense and the new uevent mechanism for doing a
rescan.  This hooks it into the standard AEN UNIT ATTENTION handling
rather than having this all done per-transport.  The only per-transport
thing we need is to trigger collection of the UA on the transport
specific AEN.

James

RE: Question on SCSI target scan

[Ewan Milne]

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

RE: Question on SCSI target scan

[Elliott, Robert (Server Storage)]

> -----Original Message-----
> From: Ewan Milne [mailto:emilne@redhat.com]
> Sent: Monday, 18 November, 2013 11:29 AM
> To: Elliott, Robert (Server Storage)
> Cc: Ramesh Chikkanayakanahally; linux-scsi@vger.kernel.org;
> jbottomley@parallels.com
> 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

RE: Question on SCSI target scan

[Ewan Milne]

On Thu, 2013-11-21 at 17:37 +0000, Elliott, Robert (Server Storage)
wrote:
> 
> > -----Original Message-----
> > From: Ewan Milne [mailto:emilne@redhat.com]
> > Sent: Monday, 18 November, 2013 11:29 AM
> > To: Elliott, Robert (Server Storage)
> > Cc: Ramesh Chikkanayakanahally; linux-scsi@vger.kernel.org;
> > jbottomley@parallels.com
> > 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