On Mon, Sep 22, 2008 at 9:39 AM, Hannes Reinecke <[EMAIL PROTECTED]> 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.
> The best we can do here is to make this re-discovery conditional, which would 
> allow customers not
> suffering from STP failures to get a faster booting time.

Current implementation only partially solves the issue, but creates
another problem instead - node parameters are changed.
What if first login will ignore this error and and retry anyway - this
is not the cleanest solution but it will satisfy both requirements.

>
>>> Another issue is that the script logouts only from automatic nodes (not 
>>> from all nodes as in redhat).
>>> This causes a bug, when iscsi is stopped while manual node is still 
>>> logged-in (session is active).
>>> The result is that iscsid is down but session is still alive - iscsiadm -m 
>>> session shows this stale session.
>>> I suggest that we do the same as redhat, any objections?
>>>
> Ouch. You touched a very complicated topic. I've had long discussions and 
> patches with NetApp on
> how to get iscsi shutdown right. It's not only that we have stale nodes 
> (which would be ok, given
> that we're shutting down anyway), but it's also well possible that some 
> crucial filesystem bits
> are in fact served by iSCSI, so we definitely shouldn'd be shutting them 
> down, regardless of any
> automatic settings.

Having stale nodes is not ok, since we may use "iscsi stop" not only
when machine shutdowns
but also to change node parameters (e.g. node_transport set to iser).
The dependency of filesystem with iscsi should be resolved
independently by the user.
This applies both for automatic and manual sessions.
What we suggest is to logout all nodes (and not only automatic).

>
> There's a bugzilla open to get this right (Novell bug#392080), you're welcome 
> to join and get
> this sorted out.
I could not find this bug, please send a link.


Thanks,
Eli

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