Re: EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)
Konrad Rzeszutek wrote:
In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we
would
logout, and then retry logging back in:
- 28Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for
connection^M
- 28Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2
attempts)^M
And we would have a short hiccup (5 seconds) of the connection being gone.
This as my understanding was a mechanism for the EqualLogic box to move
(re-establishing
allegiance) a session to a different port, hence allowing a load-balancing
mechanism.
In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed
this
behavior so that we now actually logout and delete the session. No more
retries.
Do you mean the session is destoryed as in the kernel parts are
cleaned/freed up and the iscsid parts are freed? There was a bug in 869
where the session would get destoryed on some errors it did not in 868,
but for 870.2 this is fixed (well we just almost never destroy the session).
2.0-865:
static int iscsi_xmit_mtask(struct iscsi_conn *conn)
{
struct iscsi_hdr *hdr = conn-mtask-hdr;
int rc, was_logout = 0;
spin_unlock_bh(conn-session-lock);
if ((hdr-opcode ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT) {
conn-session-state = ISCSI_STATE_IN_RECOVERY;
iscsi_block_session(session_to_cls(conn-session));
...
2.0-869:
static int iscsi_xmit_mtask(struct iscsi_conn *conn)
{
struct iscsi_hdr *hdr = conn-mtask-hdr;
int rc;
if ((hdr-opcode ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT)
conn-session-state = ISCSI_STATE_LOGGING_OUT;
spin_unlock_bh(conn-session-lock);
.. and..
if (conn-session-state == ISCSI_STATE_LOGGING_OUT) {
iscsi_free_mgmt_task(conn, conn-mtask);
conn-mtask = NULL;
continue;
}
This comes down to 2.0-869 terminating the session without trying to re-login.
What version of 869 are you using? We fixed a problem like this in the
868 test releases for RHEL and it is in upstream (I do not remember the
commit).
I do not think the code you quoted was the problem though, so maybe it
is a different issues (I tried the current code and it worked for me in
870.2). The logout would get sent, then when we clean up the session by
calling stop conn, we should set the session-state to start accepting
commands again:
iscsi_start_session_recovery():
if (flag == STOP_CONN_TERM)
session-state = ISCSI_STATE_TERMINATE;
else if (conn-stop_stage != STOP_CONN_RECOVER)
session-state = ISCSI_STATE_IN_RECOVERY;
So when we go to transmit the login mtask the session-state should not
be logging out anymore.
--~--~-~--~~~---~--~~
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
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)
Mike Christie wrote: Konrad Rzeszutek wrote: In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we would logout, and then retry logging back in: - 28Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for connection^M - 28Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2 attempts)^M And we would have a short hiccup (5 seconds) of the connection being gone. This as my understanding was a mechanism for the EqualLogic box to move (re-establishing allegiance) a session to a different port, hence allowing a load-balancing mechanism. In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed this behavior so that we now actually logout and delete the session. No more retries. Do you mean the session is destoryed as in the kernel parts are cleaned/freed up and the iscsid parts are freed? There was a bug in 869 where the session would get destoryed on some errors it did not in 868, I meant 865. --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)
In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we
would
logout, and then retry logging back in:
- 28Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for
connection^M
- 28Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2
attempts)^M
And we would have a short hiccup (5 seconds) of the connection being gone.
This as my understanding was a mechanism for the EqualLogic box to move
(re-establishing
allegiance) a session to a different port, hence allowing a load-balancing
mechanism.
In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed this
behavior so that we now actually logout and delete the session. No more retries.
2.0-865:
static int iscsi_xmit_mtask(struct iscsi_conn *conn)
{
struct iscsi_hdr *hdr = conn-mtask-hdr;
int rc, was_logout = 0;
spin_unlock_bh(conn-session-lock);
if ((hdr-opcode ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT) {
conn-session-state = ISCSI_STATE_IN_RECOVERY;
iscsi_block_session(session_to_cls(conn-session));
...
2.0-869:
static int iscsi_xmit_mtask(struct iscsi_conn *conn)
{
struct iscsi_hdr *hdr = conn-mtask-hdr;
int rc;
if ((hdr-opcode ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT)
conn-session-state = ISCSI_STATE_LOGGING_OUT;
spin_unlock_bh(conn-session-lock);
.. and..
if (conn-session-state == ISCSI_STATE_LOGGING_OUT) {
iscsi_free_mgmt_task(conn, conn-mtask);
conn-mtask = NULL;
continue;
}
This comes down to 2.0-869 terminating the session without trying to re-login.
With the EqualLogic boxes that means we never reconnect back.
So.. my question is : was this change intentional?
If so, does Equallogic know this and have they changed their firmware to
send ISCSI_ASYNC_MSG_DROPPING_CONNECTION (0x02) instead back?
--~--~-~--~~~---~--~~
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
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)
On Wed, Feb 04, 2009 at 04:33:13PM -0500, Konrad Rzeszutek wrote: In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we would logout, and then retry logging back in: - 28Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for connection^M - 28Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2 attempts)^M And we would have a short hiccup (5 seconds) of the connection being gone. This as my understanding was a mechanism for the EqualLogic box to move (re-establishing allegiance) a session to a different port, hence allowing a load-balancing mechanism. In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed this The right git commit was: commit b3a7ea8d50f6028964b468d13a095dfb2508b2fb Author: Mike Christie micha...@cs.wisc.edu Date: Thu Dec 13 12:43:26 2007 -0600 [SCSI] libiscsi: do not block session during logout There is not need to block the session during logout. Since we are going to fail the commands that were blocked just fail them immediately instead. --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
