Yet again I must have done something wrong since I was unable to set
the timeout values to zero. Yesterday I removed all saved data
meaning the nodes and send_targets directory from /etc/isci and reran
the discovery, now the values where indeed set. I did this yesterday
on two machines (one 64
Arvind wrote:
During our testing with open-iscsi initiator, we discovered a minor
issue related to MaxCmdSN. The MaxCmdSN is not re-populated after an
automatic login occurs.
This can make the initiators send more commands to the target
exceeding the MaxCmdSN sent by the target in the Login
Mike.
Thanks for quick response. Following are the answer to your questions:
Q. When the initiator logs back in, is the target sending a MaxCmdSN and
ExpCmdSn that indicates the window is smaller?
A. Yes
Q. Are you digging in the code by any chance?
A. I did a bit. Need to look more.
Q. Did
Arvind Jain wrote:
Mike.
Thanks for quick response. Following are the answer to your questions:
Q. When the initiator logs back in, is the target sending a MaxCmdSN and
ExpCmdSn that indicates the window is smaller?
A. Yes
Q. Are you digging in the code by any chance?
A. I did a
Mike Christie wrote:
Dominik L. Borkowski wrote:
We're using OpenSUSE 10.3 with open-iscsi-2.0.866-15.2 and
2.6.22.18-0.2-default SMP i686 kernel. [OpenSUSE 11 with
open-iscsi-2.0.869-8.1 had another set of issues, we couldn't even
login properly].
Weird. We had this guy that tested
Mike Christie wrote:
Arvind Jain wrote:
Mike.
Thanks for quick response. Following are the answer to your questions:
Q. When the initiator logs back in, is the target sending a MaxCmdSN and
ExpCmdSn that indicates the window is smaller?
A. Yes
Q. Are you digging in the code by any
Dominik L. Borkowski wrote:
On Friday 27 June 2008 11:44:08 Mike Christie wrote:
Dominik L. Borkowski wrote:
We're using OpenSUSE 10.3 with open-iscsi-2.0.866-15.2 and
2.6.22.18-0.2-default SMP i686 kernel. [OpenSUSE 11 with
open-iscsi-2.0.869-8.1 had another set of issues, we couldn't even
Arvind Jain wrote:
Mike,
Thanks for the patch. I came to the same conclusion after looking into the
function iscsi_update_cmdsn().
Perhaps, you could do the same thing for hdr-opcode == ISCSI_OP_NOOP_IN.
This will allow the target to dynamically adjust the window size in case of
a
Mike,
After looking into the iSCSI spec again, I realized that target can't reduce
the MaxCmdSN after the login has occurred.
The iscsi_update_cmdsn() is fine. It is doing exactly what it is suppose to
do.
I guess, if the target does have to reduce the windows size, it can send an
Mike Christie wrote:
Ken A wrote:
Yes, thanks, turning off nops helped with some of the timeouts. The
mkfs succeeded (very slowly), with this block of errors repeating
in the log (see below).
I should mention that this is on a asynchronous link, (100mbps
initiator - 1000mbps target).
Greetings Mike, Hannes, and all;
So, and Jerome and Myself have been pushing VHACS (please see towards
production, we have begin to run into a particular issue while during
the 'vhacs cluster -I' (eg: cluster initilization) routine when we had a
bunch of VHACS server and client clouds active,
On Fri, 2008-06-27 at 16:00 -0700, Nicholas A. Bellinger wrote:
Greetings Mike, Hannes, and all;
So, and Jerome and Myself have been pushing VHACS (please see towards
Whoops, forgot to include the VHACS link. :-)
http://linux-iscsi.org/index.php/VHACS
--nab
production, we have begin to
12 matches
Mail list logo
