Hannes Reinecke wrote:
> Mike Christie wrote:
>> Mike Christie wrote:
>>> Hey,
>>>
>>> When the iscsi scripts run they assume the network is ready to go. This 
>>> may not be the case for lots of different reasons, and to get around 
>>> this we have the login retry param in iscsi.conf. What we really want is 
>>> the login retry param, combined with the ability to know that the 
>>> network is up. To do this, I have been looking at libdbus and netreport, 
>>> in the hope that when the network is up, we can just fire off "iscsiadm 
>>> -m node -L automatic".
>>>
>>> Before I do this though, I wanted to see if anyone have any opinion on 
>>> dbus or netreport? Will one be a problem for any distro?
>>>
>> Oh yeah, here is a really basic patch for netreport usage. Right now it 
>> is really dumb, since we do not konw if the network is going up or down, 
>> and all we do is try to login to the records marked autoatmic. We of 
>> course should only waste our time trying to log in when the network is 
>> up and should try to figure out if it is a interface we even care about.
>>
> I doubt this will help.
> 
> The problem we're facing here is due to network routing in the connected
> switches.
> When using static IP addresses the switch has to set-up the route from
> the initiator to the requested target using the tree-spanning algorithm.
> This will take some time to setup, during which any connect() attempt
> from the initiator will fail with -EHOSTUNREACH.
> 
> But as the in-kernel iSCSI tcp code is essentially stateless, it cannot
> differentiate between failures upon startup (where EHOSTUNREACH might
> be retried) and real failures during normal operations (where
> EHOSTUNREACH is indeed a critical failure).
>

We have this already:

# To speficy the number of times iscsiadm should retry a login
# to the target when we first login, modify the following line.
# The default is 4. Valid values are any integer value. This only
# affects the initial login. Setting it to a high value can slow
# down the iscsi service startup. Setting it to a low value can
# cause a session to not get logged into, if there are distuptions
# during startup or if the network is not ready at that time.
node.session.initial_login_retry_max = 4

We do the connect() call in userspace so initiatror.c can distinguish 
between the first login and a relogin. With the above param, for all 
errors we will retry the login/connect 
node.session.initial_login_retry_max times. I guess that is why that 
worked for some people. It was just retrying the EHOSTUNREACH X times :)

Do you think the node.session.initial_login_retry_max setting is good 
enough, or do you want me to add a check for the first login and 
EHOSTUNREACH, and then always retry the error a couple times for the user?

> Note, this is while the network card has signalled the network is up,
> as from the POV of the card it is.

Ah ok. I misunderstood the problem.

> 
> We could circumvent this by pinging a target marked as automatic upon
> startup, but of course this will fail if no targets are configured ...
> 
> So this a real bugger. And I have no idea how to solve it properly.
> 
> That's why I'm using DHCP. There the routes are already setup as
> the DHCP reply somehow has to find its way back to the initiator ...
> 

Thanks for the info.

--~--~---------~--~----~------------~-------~--~----~
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