iSCSI: establish a nexus with everything you see?

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

I've changed the subject line cause we're going off on a tangent that isn't
really associated with conservative reuse.

> > If that's indeed so, the assertion that it's only the external factors
> > that decide
> > nexii is not always true.  Consider the case of an FC initiator 
> > port discovering target ports using an FC Name Server, and an iSCSI
> > initiator port discovering target ports using a "SendTargets" 
> > command.  In either case,
> > the initiator SCSI port may not really establish a nexus 
> > with a discovered target SCSI port, unless the application (or
> > even the SCSI class driver) really wants to do an I/O 
> >(starting with an open() system call in Unix systems).
> 
> I strongly disagree with that.  Virtually all commercial OS
implementations
> of SCSI do aggressive establishments of the nexii as part of the boot
sequence,
> as SCSI code tends to expect a "bus walker" to find devices in the boot
> sequence, and make sure they work.  Put a trace analyzer to work on a boot
> and watch all the TEST UNIT READY and similar commands flow by.  Is anyone
> making significant changes to this "bus walker" boot paradigm out there?

I disagree with your notion of the "aggressive establishments" behavior
being good and desirable.  In practical implementations, it causes many
problems for FC networks when these over-zealous implementations grab disks
that aren't intended for them.  Elaborate zoning methods were developed to
try to alleviate these problems and haven't necessarily helped due to the
complexity of configuring larger FC networks.  Companies have made money
developing software that reside between the host SCSI layer and FC drivers
that "see" all the FC disks, but only establish nexus with those that have
been properly allocated to this host :-)

When you say "Virtually all commercial OS implementations" you must mean MS
and Sun OS?  Cause I can think of others that don't establish SCSI nexus in
this manner.  The whole concept of "plug-n-play" belies the notion that SCSI
nexus must exist at boot time.

> There's also a subtle issue to watch out for here in that this delays
> error discovery - if the shared persistent reservations are being
> used by cluster software, discovering that the alternate path nexus can't
> be established when trying to fail over to it is way too late.  For things
> like quorum volumes, I'm fairly sure that cluster software checks all the
> access paths at initialization time, but can someone familiar with cluster
> software comment on whether the alternate access paths needed for failover
> of application volumes are checked in advance, vs. relying on the OS to
> complain if the SCSI connection to the device didn't set up correctly?

Cluster software is a whole nother ballgame.  I don't see how this is tied
to the "agressive establishment" idea, except loosely.  I'd expect a network
with clustering software to be set up much differently than a simpler
"singly attached storage" environment.  Early iSCSI clustering networks may
have to have SCSI nexus "preconfigured" in some manner to efficiently boot
and bring up all alternate paths.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard