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

[ronnie sahlberg]

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.



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