[dm-devel] RFC: one more time: SCSI device identification

[Erwin van Londen]

On Wed, 2021-04-28 at 06:34 +0000, Martin Wilck wrote:
> On Wed, 2021-04-28 at 11:01 +1000, Erwin van Londen wrote:
> > 
> > The way out of this is to chuck the array in the bin. As I mentioned
> > in one of my other emails when a scenario happens as you described
> > above and the array does not inform the initiator it goes against the
> > SAM-5 standard.
> > 
> > That standard shows:
> > 5.14 Unit attention conditions
> > 5.14.1 Unit attention conditions that are not coalesced
> > Each logical unit shall establish a unit attention condition whenever
> > one of the following events occurs:
> >         a) a power on (see 6.3.1), hard reset (see 6.3.2), logical
> > unit reset (see 6.3.3), I_T nexus loss (see 6.3.4), or power loss
> > expected (see 6.3.5) occurs;
> >         b) commands received on this I_T nexus have been cleared by
> > a command or a task management function associated with another I_T
> > nexus and the TAS bit was set to zero in the Control mode page
> > associated with this I_T nexus (see 5.6);
> >         c) the portion of the logical unit inventory that consists
> > of administrative logical units and hierarchical logical units has
> > been changed (see 4.6.18.1); or
> >         d) any other event requiring the attention of the SCSI
> > initiator device.
> > 
> > Especially the I_T nexus loss under a is an important trigger.
> > 
> > ---
> > 6.3.4 I_T nexus loss
> > An I_T nexus loss is a SCSI device condition resulting from:
> > 
> >  a) a hard reset condition (see 6.3.2);
> >  b) an I_T nexus loss event (e.g., logout) indicated by a Nexus Loss
> > event notification (see 6.4);
> >  c) indication that an I_T NEXUS RESET task management request (see
> > 7.6) has been processed; or
> >  d) an indication that a REMOVE I_T NEXUS command (see SPC-4) has
> > been processed.
> > An I_T nexus loss event is an indication from the SCSI transport
> > protocol to the SAL that an I_T nexus no
> > longer exists. SCSI transport protocols may define I_T nexus loss
> > events.
> > 
> > Each SCSI transport protocol standard that defines I_T nexus loss
> > events should specify when those events
> > result in the delivery of a Nexus Loss event notification to the SAL.
> > 
> > The I_T nexus loss condition applies to both SCSI initiator devices
> > and SCSI target devices.
> > 
> > If a SCSI target port detects an I_T nexus loss, then a Nexus Loss
> > event notification shall be delivered to
> > each logical unit to which the I_T nexus has access.
> > 
> > In response to an I_T nexus loss condition a logical unit shall take
> > the following actions:
> > a) abort all commands received on the I_T nexus as described in 5.6;
> > b) abort all background third-party copy operations (see SPC-4) that
> > are using the I_T nexus;
> > c) terminate all task management functions received on the I_T nexus;
> > d) clear all ACA conditions (see 5.9.5) associated with the I_T
> > nexus;
> > e) establish a unit attention condition for the SCSI initiator port
> > associated with the I_T nexus (see 5.14
> > and 6.2); and
> > f) perform any additional functions required by the applicable
> > command standards.
> > ---
> > 
> > This does also mean that any underlying transport protocol issues
> > like on FC or TCP for iSCSI will very often trigger aborted commands
> > or UA's as well which will be picked up by the kernel/respected
> > drivers.
> 
> Thanks a lot. I'm not quite certain which of these paragraphs would
> apply to the situation I had in mind (administrator remapping an
> existing LUN on a storage array to a different volume). That scenario
> wouldn't necessarily involve transport-level errors, or an I_T nexus
> loss. 5.14.1 c) or d) might apply, is that what you meant?

I was indeed mostly referring to:

 	c) the portion of the logical unit inventory that consists
 of administrative logical units and hierarchical logical units has
 been changed (see 4.6.18.1); or
 	d) any other event requiring the attention of the SCSI
 initiator device.

The IT nexus status itself might not have changed but if an abstraction
layer representing a totally different set of data that would most
definitely fall under d. I think swapping between a volume and one of
its snapshots also falls under this 


> 
> Regards
> Martin
>