> On Feb 4, 2016, at 7:00 PM, Chris Leech <[email protected]> wrote: > > > 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.
For the session_is_running checks, we do not really need to check sysfs. I originally did this because I was worried other tools would be creating sessions using some other tools or accessing netlink. This never happened - ignore the possible qla4xxx case for now. If someone is using their tool and ours then I think it is ok. It is not a big deal. 1. We can remove the __session_login_task->session_is_running->iscsi_sysfs_for_each_session->iscsi_match_session. 2. I think we can also remove the iscsi_check_for_running_session call from update_sessions when discoveryd is used. If we just do the iscsi_login_portal_nowait call, the normal session_login_task check will figure things out like normal. 3. The iscsiadm iscsi_check_for_running_session calls in verify_node_params, delete_node, and exec_iface_op are not issues right? They happen pretty rarely. For the session counting checks, can we track the counts in iscsid too? If the login request put us over the limit, just fail it. > > - 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. -- 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.
