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. > > Bottom line: I did not find any way to significantly speed > up the search other than the "cache the last session" > patch I already posted. Can you explain the problem again? I thought originally you were thinking it was due to the sysfs operations taking too long and then compounded by them being repeated. However, I thought for the discoveryd daemon process, sysfs.c is caching that info, so we are not actually reading from sysfs every time. Is the issue just a normal old bad search cpu time type of issue and not really sysfs read/scan operations taking a long time? If so, then the patch makes sense. -- 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 open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
