On Nov 28, 2014, at 5:46 PM, The Lee-Man <[email protected]> wrote:
> 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? If you just do something that causes the iscsi layer to go into recovery like a cable pull then no. The kernel and iscsid structures will stay in place and we will reuse them. > > 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. Did you mean iscsi or iscsid? Do you guys have just the one iscsi service? We have iscsi and iscsid in RHEL and they work much differently. > I also was using discovered. Don’t have SUSE handy. You will have to tell me what happens when you do the stop command. > > 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. Stale here is supposed to mean portals that are longer returned by the target. If you are seeing something else then there is a bug. That is why I asked if the target was returning different targets. For a cable pull test or your test, it should be returning the same targets right. For your test I think you are also hitting a bug where if iscsid is not being restarted too (you are just logging out and into sessions), then its discovered cache is messed up. Looks like there is bug where because discoveryd is caching sysfs info, if you were to run iscsiadm …logout then iscsiadm … login, discovered will have a /sys/class/iscsi_session entry for the old session as well as the new one. Not sure how badly that is messing your test up or at all. You should disable discoveryd caching. > > > > > 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, …) I am not sure what code are you talking about? I am not seeing where there is s session ID available in update_sessions or where we are passing in a wild card. discoveryd does not really know about the sessions. It more works with node records. That is why it has to loop around the sessions to try and figure out what session goes with what node record. Are you just speaking more generically like we should add some code for update_session to able to store/get the session id. > -- > 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. -- 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.
