On Wednesday, November 26, 2014 1:11:46 PM UTC-8, Mike Christie wrote: > > On 11/25/2014 05:15 PM, The Lee-Man wrote: > > On Tuesday, November 25, 2014 2:00:22 PM UTC-8, Mike Christie wrote: > > > > On 11/25/2014 12:49 PM, The Lee-Man wrote: > > > On Tuesday, November 25, 2014 9:42:59 AM UTC-8, Mike Christie > wrote: > > > > > > On 11/24/2014 11:04 AM, The Lee-Man wrote: > > > > Okay, I spent most the day yesterday playing with the > > > > code in question, i.e. the open-iscsi code that rescans > > > > the session list looking for the current session. > > > > > > > > In particular, I was looking at update_sessions(). > > > > > > > > One thing I noticed is that this code only gets executed > > > > if discovery.sendtargets.use_discoveryd is set to Yes for > > > > a particular target, by the way. > > > > > > So how does your interconnect test come into play for this > > issue? It > > > seems like you should be hitting this issue all the time even > > when the > > > connection is ok, because that code polls every N seconds. > > > > > > > > > When the connections are being dropped and then reconnected, the > > > sessions (created by the kernel) are coming and going. And each > time > > > a connection goes away and comes back, it gets a new session ID, > > > and a new symlink in /sys/class/iscsi_sessions, which of course > > > is not cached. (This is my theory, since I don't have a > configuration > > > which can test this ATM.) > > > > The session and/or connection id does not change if the connection > is > > just dropped and then relogged into by iscsid. It would only change > if > > you are removing a session by hand by doing iscsiadm ... --logout, > then > > readding it by doing iscsiadm .... --login, or if maybe discoveryd > is > > causing sessions to be deleted then added due to getting different > > portals back or due to a bug in that code. > > > > Or, are you using eql's multipating software that might be > dynamically > > creating/deleting sessions? > > > > > > Not using eql multipathing (I don't believe). > > > > When I stop iscsid and restart it, I get a new session ID. > > > > Any time a session is removed from the kernel then readded it can change. >
So if a connection was removed, so that all of the sessions on that connection go into error handling, will they not be removed eventually, if retries do not work? > > How do you start and stop it? Are you just killing the daemon by doing a > sigkill and restarting it by running /sbin/iscsid? If so, it should not > change. > For my testing, on SLES 12, I was using sytsemctl (systemd) to start/stop iscsi. I also was using discoveryd. > > When you kill iscsid are you also removing the sessions then on restart > are you creating them again? If so, then yeah the session id will change > because you are removing the session like is done when you do --logout. > Maybe you are using some init/systemd type of script? > Yes. Again, this was just for my testing. The original testing done by a large hardware manufacturer instead just pulled cables. But it looks like update_sessions() logs out of stale sessions. > > > > I have not learned the code enough to answer this question, so I'll ask > > you, to make sure. > > > > Is there nothing else that changes the session ID? > > Just a complete removal from the kernel like is done when the --logout > command is run manually or when discoveryd does it. Look at > iscsi_add_session() in drivers/scsi/scsi_transport_iscsi.c for when it > gets set. It then never changes. > > In older versions iscsid could also remove a session if during login we > got a response that indicated the target was no longer there. We stopped > doing that though. Original problem occurred on SLE 11 SP3, which is based on 2.0.873, with SUSE patches. > > > Also, I do not know what the init scripts or systemd or network manager > does in suse, so I have no idea if there are cases where you might be > deleting sessions then readding them. I have seen some distros delete > sessions when the network goes down, then login again when the network > comes back up. For these cases though, they run the iscsiadm > logout/login commands. > Yes, again, in my testing only I was logging out of sessions, stopping iscsid, then starting iscsid and re-logging in. But original problem did not do this. > > > > > > The current code in update_sessions() passes in zero for the session ID, > > which means "match any session ID". > > I did not understand this comment wrt session ids changing. > > My comment was directed at the fact that the search for a matching session cannot be done in O(1) without caching. If the code passed in a session ID when searching for a matching session, it could simply look it up via /sys/class/iscsi_sessions/session<N>. But since the code passes in a wild card value, the search code specifically ignored session ID and matches on the other attributes passed in (e.g. target name, address, ...). -- 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 http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
