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. 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
