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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to