So increasing the ISID space gets this working, but the described setup here (4 sessions x 256 targets) takes a _long_ time to connect to all the targets. In a virtual setup I'm seeing up to 10 minutes, and with higher network latencies and busy targets I can imagine it being worse.
Just an FYI that I'm looking at it, as there seems to be a lot of overhead in repeatedly reading in sysfs data. Both iscsiadm and iscsid spend most of their time in strcmp. Once this many sessions are active, given an additional login command just counting them up to decide if more sessions are needed or not takes up to 5 seconds. Hacking out the session counting and session_is_running checks drops the time from 9-10 minutes to about 30 seconds. Not a solution, but maybe an good indication of where the problem is. - Chris On Thu, Jan 28, 2016 at 12:19:39PM -0800, shiva krishna merla wrote: > Hi All, > > We are seeing an issue with Redhat 6.7 where ISID's are repeated for > different sessions to same target (volume level target). Our array target > has to close the existing sessions with same ISID before accepting new > connections. This causes repeated login retry attempts by iscsid and > overall system discovery process is too slow. From the code i see that ISID > is determined as below. With this many sessions above 256 can have repeated > ISID. Is this a design flaw?. Can this be avoided?. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
