On 11/10/09 11:39 AM, Mike Christie micha...@cs.wisc.edu wrote:
What version of open-iscsi were you using and what kernel, and were you
using the iscsi kernel modules with open-iscsi.org tarball or from the
kernel?
iscsi-initiator-utils-6.2.0.871-0.10.el5
kernel-2.6.18-164.2.1.el5
RedHat
Matthew Dickinson wrote:
On 11/10/09 11:39 AM, Mike Christie micha...@cs.wisc.edu wrote:
What version of open-iscsi were you using and what kernel, and were you
using the iscsi kernel modules with open-iscsi.org tarball or from the
kernel?
iscsi-initiator-utils-6.2.0.871-0.10.el5
sorry... wrong information. Here is the correct information. I was doing some
testing in VMWare Fusion VM's for a presentation that I'm giving. The
storage server is CentOS 5.3, which dishes out IETD targets for my OVM
servers. The OVM 2.2 environment is as follows:
[r...@ovm1 ~]# uname
Hoot, Joseph wrote:
I've had about 3 threads of dt (kicking off a bit randomly) on (3) separate
volumes for over a week and haven't had a single disconnect yet. I am
currently using whatever rpm is distributed with Oracle VM v2.2. I know for
sure that they have included the 871 base,
[r...@storage ~]# uname -r
2.6.18-164.el5
[r...@storage ~]# rpm -qa | grep iscsi
iscsi-initiator-utils-6.2.0.868-0.18.el5_3.1
[r...@storage ~]#
On Nov 10, 2009, at 12:17 PM, Mike Christie wrote:
Hoot, Joseph wrote:
I've had about 3 threads of dt (kicking off a bit randomly) on (3) separate
Matthew Dickinson wrote:
On 11/6/09 3:39 PM, Matthew Dickinson matt-openis...@alpha345.com wrote:
Try disabling nops by setting
node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
I'm still getting errors:
Nov 10 09:08:04 backup kernel: connection12:0:
Hoot, Joseph wrote:
[r...@storage ~]# uname -r
2.6.18-164.el5
[r...@storage ~]# rpm -qa | grep iscsi
iscsi-initiator-utils-6.2.0.868-0.18.el5_3.1
[r...@storage ~]#
Weird.
Is 2.6.18-164.el5 the kernel being used in the virtual machine/DonU? Is
that where you are using iscsi? It looks
El 06/11/09 14:10, mdaitc escribió:
Hi mdaitc,
I’m seeing similar TCP “weirdness” as the other posts mention as well
as the below errors.
(..)
Nov 2 08:15:14 backup kernel: connection33:0: detected conn error
The performance isn’t what I’d expect:
(..)
What happens if you disable TCP
What version of OiS are you using? I had lots of weirdness and the
same types of disconnects to our Dell EqualLogic when we were
(actually still are in production) using 868 code. I'm now using open-
iscsi-871 code plus a sendwait patch and haven' had the issue. I've
now been slamming
Hi all,
I am working on iSCSI En. Tar. Could you please someone explain about the
performance of the IET.
If so how the performance was calculated and what was the througput for the
same.
Thanks
Gopala krishnan Varatharajan
On Sat, Nov 7, 2009 at 3:09 AM, Matthew Dickinson
Hoot, Joseph wrote:
What version of OiS are you using? I had lots of weirdness and the
same types of disconnects to our Dell EqualLogic when we were
(actually still are in production) using 868 code. I'm now using open-
iscsi-871 code plus a sendwait patch and haven' had the issue.
it was for OiS 871 code prior to RHEL 5.4 release (not sure if the
release include it or not). I'm not sure who came up with it. I was
working with Don Williams from Dell EqualLogic. He got ahold of it
somehow. I applied it and it seemed to improve things.
On Nov 9, 2009, at 2:31 PM,
Hoot, Joseph wrote:
it was for OiS 871 code prior to RHEL 5.4 release (not sure if the
release include it or not). I'm not sure who came up with it. I was
working with Don Williams from Dell EqualLogic. He got ahold of it
somehow. I applied it and it seemed to improve things.
Ah
I've had about 3 threads of dt (kicking off a bit randomly) on (3) separate
volumes for over a week and haven't had a single disconnect yet. I am
currently using whatever rpm is distributed with Oracle VM v2.2. I know for
sure that they have included the 871 base, plus I believe at least a
El 03/11/09 0:52, Mike Christie escribió:
Dear Mike,
You can turn off ping/nops by setting
node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
(set that in iscsid.conf then rediscovery the target or run iscsiadm -m
node -T your_target -o update -n
Santi Saez wrote:
Hi,
Randomly we get Open-iSCSI conn errors when connecting to an
Infortrend A16E-G2130-4 storage array. We had discussed about this
earlier in the list, see:
http://tr.im/DVQm
http://tr.im/DVQp
Open-iSCSI logs this:
Hi!
I would guess that your network/storage system is overloaded occasionally, and
then network packets are significantly (5s) delayed. It sounds unlikely, but
that
would explain a duplicate ACK IMHO.
Here with SLES10 SP2 on x86_64 with a HP EVA 6000 + iSCSI connectivity option
(MPX100)
17 matches
Mail list logo
