On 3/20/19 7:32 PM, Rao Shoaib wrote: > Hi, Hi! Please direct questions at the open-iscsi group on googlegroups, so others can contribute to and/or benefit from the discussion.
> > In the commit of the above change you say > > "But, make no > mistake, it is recommended not to retry forever, as it leaves > iscsid stuck in "iscsi_sysfs_for_each_session()" in iscsid.c:main(), > so iscsid never fully gets up and running." > > I do not see how iscsid will get stuck as it forks and does not wait for > the child to finish. Can you kindly explain it to me. > > Regards, > > Shoaib > > TL;DR ===== That statement was partly incorrect. It's not that bad, but it's still bad. DETAILS ======= There are two effects from letting the forked child process try forever to recover a session, assuming that the session cannot or will not ever be recovered: 1. If there are multiple sessions to be recovered, the recovery is done in serial, so if the process tries forever to recover any particular session, other sessions waiting in line behind it will never be recovered. If there are thousands of sessions this would be bad. NOTE: there is an option to do this in parallel, but that has never been tested and is not enabled. 2. The systemd "state" will be "Ready"/"Syncing external sessions(s)" until the resync completes, and "Ready"/"Ready to process requests" when done. In an environment where one expects each and every session to be recovered, or else there's a problem, then retrying forever might make sense. But in an environment like cloud computing, where sessions might come and go, and you might never see that session again, retrying forever is not good. And, by the way, it only occurs when the service is stopped and restarted, so if some session has "gone away" it may have gone away a LONG time ago and is only discovered when the service/system restarts, which sometimes is way too late to do much about it. I prefer a system using iSNS where targets and initiators can get notifications of changes, but such a configuration does not seem very popular. Even so, if I had a product based on iscsi connections, I would write some sort of daemon that periodically checked connections, kept track of which ones went away as planned and which ones should be retried and for how long. Sort of like the discovery daemon in iscsid, but better. Or maybe submit patches to iscsid to improve/enhance the discovery daemon. :) SUMMARY ======= But to get back to your initial question, the major functionality of iscsid is *not* compromised when it is retrying forever to reconnect a stale session, though it *is* wasting resources and can have other negative side-effects, as listed above. -- The Lee-Man -- 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.
