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