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