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@xxxxxxxxxxxxxxx [mailto:linux-scsi-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Ramesh Chikkanayakanahally
> Sent: Wednesday, 06 November, 2013 8:10 AM
> To: linux-scsi@xxxxxxxxxxxxxxx
> Cc: jbottomley@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
