On Tue, Sep 23, 2008 at 12:13:19PM -0500, Mike Christie wrote:
> Hannes Reinecke wrote:
>> Hi Doron,
>> Doron Shoham wrote:
>>> Doron Shoham wrote:
>>>> Hi,
>>>>
>>>> Why does the init script on suse re-discovers all iscsi targets which 
>>>> were set
>>>> to automatic login?
>>>> To avoid deadlocks on the root fs there is patch which limits the number 
>>>> of retries on first login.
>>>> When doing so, it sets back all the default parameters (overriding any 
>>>> user definitions).
>>>> I think it should be like in redhat - just login to all the targets 
>>>> which are automatic.
>>>>
>> That's what we tried initially. However, certain switches take quite a bit 
>> of time for the Spanning-Tree
>> Protocol to work out the route, during which time any connect() attempt 
>> returns with -EHOSTUNREACH.
>> If we do an automatic login, the login request is sent from the kernel 
>> directly. And any connect()
>> failure from the kernel is taken as a terminal error, hence the login 
>> fails.
>
> Are we talking about the same thing that keeps coming up :)
>
I know. Main reason here is that I didn't have time to investigate
this further, so I'll have to fall back to answer the same results
I had the last time ...

> I swear someone from Voltaire asked this before. You gave the same reply. 
> And then I said you can increase node.session.initial_login_retry_max
> so we retry the login for all cases (almost all not CHAP or target not 
> there errors). If we get -EHOSTUNREACH we will retry up to 
> node.session.initial_login_retry_max times (there is a 1 second delay 
> between retries so it is a delay of node.session.initial_login_retry_max 
> seconds). I then said that for -EHOSTUNREACH I can add a check so that we 
> always test for this and always retry so the user does not have to set 
> node.session.initial_login_retry_max but I was not sure if there was a case 
> where we would not want to retry.
>
Problem is that there are valid cases for which we should _not_ retry an
-EHOSTUNREACH failure case. So I wouldn't retry for EHOSTUNREACH always.
But increasing the initial_login_retry_max value would really help here.
Hmm. Will have to check, but this seems like a viable route.

Sorry for not being responsive, but I've been kept really busy recently.

> I can even increase the default node.session.initial_login_retry_max. It is 
> only 4 right now. We do all the logins in parallel now, so the max delay 
> would be node.session.initial_login_retry_max seconds basically. Previously 
> when we did one portal at a time, we might have to wait 
> node.session.initial_login_retry_max for each portal or in cases like EQL 
> each device.
Ah. Good to know.

I really hope to get this cleared up in the near future.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                   zSeries & Storage
[EMAIL PROTECTED]                             +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to