Doron Shoham wrote: >> Actually this was bad. If we have to wait for the login_timeout to fire >> then initial_login_retry_max = 4 was a nice round number and the max >> time we had to wait was 1 minute. If I just increase it (tried 45 >> stupidly first), it increases the possible max default wait to 11 >> minutes :( >> >> So what I did was make initial_login_retry_max just be the max number of >> initial iscsi login timeouts we can withstand and then let other initial >> login failures retry for up to initial_login_retry_max * login_timeout. > > Have you change something in the code?
It is commit 31c9d428556088c886be3ea89333e9b116bc0a09 Author: Mike Christie <[EMAIL PROTECTED]> Date: Wed Sep 24 17:34:47 2008 -0500 modify initial login retry max > I can't see any change in the git. > Can you please explain your calculation again? It is just the same thing we do for scsi commands. login retry max * login timeout = max time to retry the initial login. So to put it in scsi command terms of retry and timeout, the login failure we see for the initial login of EHOSTNOTREACH is considered retryable like scsi-ml's DID_IMM_RETRY value, and does not count against the retry counter, but we will only retry up to the login retry max * login timeout seconds so it does not retry forever on the first login and stop up the boot process. > > I wanted to know if we are going to change back the init script. > If the problem is to wait for the spanning tree, does increasing the > initial_login_retry_max should do the work? Yes it should work around the problem - sort of :) We do not know if EHOSTNOTREACH is because of the spanning tree problem or because a cable is unplugged. For the first one we want to retry, for the second we probably do not (unless the admin is running to the box and trying to plug it back in :)). So now we set the initial login timeout and retry to a value to where most people hitting the spanning problem will be ok. At least according to the bug reports we are seeing on the list and at Red Hat if users set up those values to retry for at most 2 minutes that was long enough. The draw back is that at most we used to retry for 1 minute, so everyone else using the defaults will have to wait an extra minute which can be a pain. However everyone can change the value to fail fast or wait longer like before so hopefully this new value is a good compromise. > > Currently the init script causes other bugs. This is only meant to help Hannes in the spanning tree issue, so he does not have to use the discovery trick to work around it. For discovery though it seems like you can just do discovery and tell iscsiadm not to overwrite the existing db (just add new ones) and that would solve some of the issues with iser records getting wacked. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to firstname.lastname@example.org To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---