[stgt] tgt-admin behavior with multiple targets and same account name

[Chandra Seetharaman]

On Thu, 2010-03-04 at 01:34 +1100, ronnie sahlberg wrote:
> On Wed, Mar 3, 2010 at 9:06 AM, Chandra Seetharaman <sekharan at us.ibm.com> wrote:
> ...
> >
> > In order for the initiator to get the list of targets, initiator need to
> > provide the discovery password.
> >
> > If one has multiple targets with different users (i.e target1 has user1
> > and target2 has user2 etc.,), then there will be a problem about which
> > target's user to be used with discovery.
> >
> > So, we will need a interface that provides a single global user for
> > discovery and different users for each targets.
> >
> > Note that same user can be used between targets and for discovery(i.e
> > One can specify user user1 as incoming user for target1, target2 and
> > discovery).
> >
> 
> Good points.
> 
> This kind of leads to a second item that should be investigated/prototyped.
> 
> 
> Some people want to create one dedicated target for each individual
> initiator and then use an ACL for the luns behind each
> target to only allow that particular initiator to access those luns.
> 
> 
> So if you have n initiators and one lun each,   a naive discovery
> request would still return to a client n targets, but for each
> initiator there would only be accessible luns behind a single one of
> the targets.
> 
> For most part this works well, until certain initiators are used. For
> example linux, but also others., Not microsofts initiator though.
> Some initiators, after logging to a target and finding out that there
> are no luns available,   will still insist on remaining to be logged
> in and, if you are lucky, do a REPORTLUNS once every 30 seconds,  or
> if you are unlucky, iterate over lun 0 to 255 and use a TestUnitReady.
> 
> I guess the initiator just tries to be helpful to "automagically"
> discover new LUNs as you add them, but this leads to n^2 and there are
> never any happy endings when n^2 is involved.
> 
> 
> In any case, this leads to n^2 behaviour every 30 seconds or so when
> every n initiator will try to probe every n targets known. Not good.
> 
> 
> To avoid having to relying end-users to reconfigure the defaults on
> their initiators to avoid this, many/most iscsi targets default to a
> mode where a discovery request would ONLY return those targets where
> there are LUNs accessable to that particular initiator.
> With an option to change of course to "report all targets always" and
> let certain initiators kill the network if you have too many of them.
> 
> 

Sounds like a good feature.

> 
> I know this has been discussed previously on the stgt list but dont
> remember if it was actually implemented.
> I could check the sources tomorrow if it was implemented.
> 
> 
> It it was not, this kind of option would be VERY useful to avoid a
> large number of overly helpful initiators from taking down your
> target.
> 
> 
> 
> 
> regards
> ronnie sahlberg
> --
> To unsubscribe from this list: send the line "unsubscribe stgt" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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