On Thu, 2010-03-04 at 01:34 +1100, ronnie sahlberg wrote: > On Wed, Mar 3, 2010 at 9:06 AM, Chandra Seetharaman <sekharan@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
