State: blocked..Disc becomes unusable after target restart
KVER=`uname -r`
MODPATH=/lib/modules/${KVER}/kernel/iscsi
stop() {
ietadm --op delete
killall ietd
rm -f /var/run/iscsi_trgt.pid
rmmod $MODPATH/iscsi_trgt
modprobe -r iscsi_trgt
}
start {
modprobe iscsi_trgt
daemon /usr/sbin/ietd -d 0
}
---
Output of iscsiadm -m session -i before Target restart..
Check last entry of state of iqn.2008-04.com.qualexsystems
:Admin as running.
[EMAIL PROTECTED] ~]# iscsiadm -m session -i
iscsiadm version 2.0-742
Session (sid 42) using module tcp:
TargetName: iqn.2008-04.com.qualexsystems:Tar1
Portal Group Tag: 1
Network Portal: 192.168.7.71:3260
iSCSI Connection State: LOGGED IN
Internal iscsid Session State: NO CHANGE
Negotiated iSCSI params:
HeaderDigest: CRC32C
DataDigest: CRC32C
MaxRecvDataSegmentLength: 8192
MaxXmitDataSegmentLength: 8192
FirstBurstLength: 65536
MaxBurstLength: 262144
ImmediateData: No
InitialR2T: Yes
MaxOutstandingR2T: 1
Attached SCSI devices:
Host Number: 43 State: running
scsi43 Channel 00 Id 0 Lun: 0
Attached scsi disk sdi State: running
Session (sid 61) using module tcp:
TargetName: iqn.2008-04.com.qualexsystems:Admin
Portal Group Tag: 1
Network Portal: 192.168.7.173:3260
iSCSI Connection State: LOGGED IN
Internal iscsid Session State: NO CHANGE
Negotiated iSCSI params:
HeaderDigest: CRC32C
DataDigest: CRC32C
MaxRecvDataSegmentLength: 8192
MaxXmitDataSegmentLength: 8192
FirstBurstLength: 65536
MaxBurstLength: 262144
ImmediateData: No
InitialR2T: Yes
MaxOutstandingR2T: 1
Attached SCSI devices:
Host Number: 62 State: running
scsi62 Channel 00 Id 0 Lun: 0
Attached scsi disk sdj State: running
--
When i restared iscsi daemon on target machine.
[EMAIL PROTECTED] ~]# iscsiadm -m session -i
iscsiadm version 2.0-742
Session (sid 42) using module tcp:
TargetName: Tar1
Portal Group Tag: 1
Network Portal: 192.168.7.71:3260
iSCSI Connection State: LOGGED IN
Internal iscsid Session State: NO CHANGE
Negotiated iSCSI params:
HeaderDigest: CRC32C
DataDigest: CRC32C
MaxRecvDataSegmentLength: 8192
MaxXmitDataSegmentLength: 8192
FirstBurstLength: 65536
MaxBurstLength: 262144
ImmediateData: No
InitialR2T: Yes
MaxOutstandingR2T: 1
Attached SCSI devices:
Host Number: 43 State: running
scsi43 Channel 00 Id 0 Lun: 0
Attached scsi disk sdi State: running
Session (sid 61) using module tcp:
TargetName: iqn.2008-04.com.qualexsystems:Admin
Portal Group Tag: 1
Network Portal: 192.168.7.173:3260
iSCSI Connection State: IN LOGIN
Internal iscsid Session State: REPOEN
Negotiated iSCSI params:
HeaderDigest: None
DataDigest: None
MaxRecvDataSegmentLength: 8192
MaxXmitDataSegmentLength: 8192
FirstBurstLength: 65536
MaxBurstLength: 262144
ImmediateData: No
InitialR2T: Yes
MaxOutstandingR2T: 1
Attached SCSI devices:
Host Number: 62 State: running
scsi62 Channel 00 Id 0 Lun: 0
Attached scsi disk sdj State: blocked
MY QUES. IS
After restarting target,Why disk becomes unused on the initiator side?
Though disk remains as logged in,but becomes unusable.
---
This was ur reply
Could you resend this to the list, with an explanation of what
restarting
iscsid means. Did you leave sessions running, kill iscsid, then
restart
iscsid? If so when iscsid starts up it syncs up the sessions. It shows
the
device as blocked and the session as not logged in, because for some
reason it cannot log back in (you would need to send some more log
output
to know why (maybe run iscsid with -d 8 when you restart it).
I had tried both iscsid with -d 8 and latest initiator-target pair
as well.
Still the problem persists and disk becomes unusable after restarting
iscsi-target.
What can be the problem?Or Persistent connection is not possible.
Target Restart event
One more question in context to previous one, When ISCSI Target is restarted, /proc/net/iet/session file changes with some major delay. And this delay is not same all the time.It is sometimes less and sometimes more. After this delay,sessions are restored.But disk exported by this target becomes unusable for the Initiator logged in ito it. But ISCSI Target restart is necessary for addition/deletion of targets/ Lun changed to reflect. My aim is Persistent Connection after target restart.Means disks should be in running state rather than Blocked. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
iscsiadm doesnt resolve hostname when used in node mode
Hello,
I'm usinsg iscsiadm from iscsi-initiator-utils version
6.2.0.865-0.8.el5, and i also tried opne-iscsi 2.0.730-1etch1in a line
like this:
iscsiadm -m discovery -t sendtargets -p iscsi-storage| cut -f2 -d\ |
xargs -l -I '{}' iscsiadm -m node -T {} -p iscsi-storage -l
where iscsi-storage is defined in /etc/hosts , it fails to find iscsi-
storage in the node mode, but works fine in the discovery mode, if i
change iscsi-storage to the ip of the target in the node mode, it
works fine ... i suppose this is a bug ! no ?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Should connection restored?
When target is logged in to an initiator and then either target/ initiator is restarted,connection is lost. Should the connection be restored? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsiadm doesnt resolve hostname when used in node mode
Maysara wrote:
Hello,
I'm usinsg iscsiadm from iscsi-initiator-utils version
6.2.0.865-0.8.el5, and i also tried opne-iscsi 2.0.730-1etch1in a line
like this:
iscsiadm -m discovery -t sendtargets -p iscsi-storage| cut -f2 -d\ |
xargs -l -I '{}' iscsiadm -m node -T {} -p iscsi-storage -l
where iscsi-storage is defined in /etc/hosts , it fails to find iscsi-
storage in the node mode, but works fine in the discovery mode, if i
change iscsi-storage to the ip of the target in the node mode, it
works fine ... i suppose this is a bug ! no ?
iscsiadm takes the values that are returned from discovery. It does not
do any hostname resolution. So if the target gives us a ip address
during discovery you have to pass iscsiadm -m node ... -l a ip address.
If the target gives us hostnames then you have to use the hostnames it
gave us.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Should connection restored?
On Thu, May 08, 2008 at 08:52:35AM -0700, MAKHU wrote: When target is logged in to an initiator and then either target/ initiator is restarted,connection is lost. It goes the other way. Initiator logs in the target. If the initiator (client) is restarted the connection would be lost. If the target is restarted it might do: 1). If it a NetApp, send a command asking the initiator to logout. 2). If is a EqualLogic, send a AsyncMsg telling the initiator that the block device is going to be off-line. 3). For others it might just terminate the connection without notifying the initiator at all. At which point the nop-ping timer (which runs by default every 15 seconds) would figure out the connection is lost, kick a retry and if that failed terminate the connection. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
iscsid: received iferror -22
Hello everybody, for 2 hours now I receive LOTs of errors in my syslog: May 8 19:43:03 xenhost2 last message repeated 2 times May 8 19:43:03 xenhost2 iscsid: connection9:0 is operational after recovery (1 attempts) May 8 19:43:14 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 14:0 state (3). Dropping session. May 8 19:43:14 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 8:0 state (3). Dropping session. May 8 19:43:16 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 15:0 state (3). Dropping session. May 8 19:43:18 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 6:0 state (3). Dropping session. May 8 19:43:18 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 11:0 state (3). Dropping session. May 8 19:43:24 xenhost2 iscsid: received iferror -22 May 8 19:43:24 xenhost2 last message repeated 2 times May 8 19:43:24 xenhost2 iscsid: connection14:0 is operational after recovery (1 attempts) May 8 19:43:24 xenhost2 iscsid: received iferror -22 May 8 19:43:24 xenhost2 last message repeated 2 times May 8 19:43:24 xenhost2 iscsid: connection8:0 is operational after recovery (1 attempts) May 8 19:43:26 xenhost2 iscsid: received iferror -22 What exactly does iferror -22 mean? My system is Debian Etch 64bit running open-iscsi 2.0.865-1 from debian unstable. I am connecting to two PS400 from EqualLogic. I am running xen 3.2 from etch-backports with the block-iscsi script from http://xen.markmail.org/message/z74wb4ewxxmsyauu?q=block-iscsi . I have eth0 for LAN and eth1 for SAN on my xenhosts. I have tried enabling and disabling jumbo frames on eth1. These errors render my VMs somehow unusable. Any hints? Regards, Bjoern --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
in /var/log/messages: conn errors and recovery
Hello all, After seeing the announcement on the regression of the current release, I looked more closely into my /var/log/messages and noticed that once in a while my iscsi connections get the following: May 8 08:55:48 r05s23 kernel: connection1:0: iscsi: detected conn error (1011) May 8 08:55:49 r05s23 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) May 8 08:55:51 r05s23 iscsid: connection1:0 is operational after recovery (2 attempts) Seems like it recovers, but are these critical issues? My iscsi device is being mounted as my root; should I increase some paramater in /etc/iscsi/iscsi.conf? Any recommendation would be greatly appreciated. A. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsid: received iferror -22
Update: I just migrated back to my old system: Debian Etch Xen 3.0.3 (same open-iscsi version though) WITHOUT the block-iscsi script (here I use phy:-devs from /dev/disk/by-path). That seems to be fine (although this box has only a shared nic, one vlan for LAN another one for SAN). This is what it looks like now: May 8 19:48:09 xenhost1 kernel: SCSI device sdak: 83896320 512-byte hdwr sectors (42955 MB) May 8 19:48:09 xenhost1 kernel: sdak: Write Protect is off May 8 19:48:09 xenhost1 kernel: sdak: Mode Sense: 81 00 00 00 May 8 19:48:09 xenhost1 kernel: SCSI device sdak: drive cache: write through May 8 19:48:09 xenhost1 kernel: SCSI device sdak: 83896320 512-byte hdwr sectors (42955 MB) May 8 19:48:09 xenhost1 kernel: sdak: Write Protect is off May 8 19:48:09 xenhost1 kernel: sdak: Mode Sense: 81 00 00 00 May 8 19:48:09 xenhost1 kernel: SCSI device sdak: drive cache: write through May 8 19:48:09 xenhost1 kernel: sdak: sdak1 sdak2 May 8 19:48:09 xenhost1 kernel: sd 37:0:0:0: Attached scsi disk sdak May 8 19:48:09 xenhost1 kernel: scsi38 : iSCSI Initiator over TCP/IP May 8 19:48:10 xenhost1 iscsid: received iferror -22 May 8 19:48:10 xenhost1 last message repeated 2 times May 8 19:48:10 xenhost1 iscsid: connection30:0 is operational now iferror -22 is still there but only directly after iscsi login. No more entries after that. Sigh... /Bjoern Bjoern Metzdorf wrote: Hello everybody, for 2 hours now I receive LOTs of errors in my syslog: May 8 19:43:03 xenhost2 last message repeated 2 times May 8 19:43:03 xenhost2 iscsid: connection9:0 is operational after recovery (1 attempts) May 8 19:43:14 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 14:0 state (3). Dropping session. May 8 19:43:14 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 8:0 state (3). Dropping session. May 8 19:43:16 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 15:0 state (3). Dropping session. May 8 19:43:18 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 6:0 state (3). Dropping session. May 8 19:43:18 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 11:0 state (3). Dropping session. May 8 19:43:24 xenhost2 iscsid: received iferror -22 May 8 19:43:24 xenhost2 last message repeated 2 times May 8 19:43:24 xenhost2 iscsid: connection14:0 is operational after recovery (1 attempts) May 8 19:43:24 xenhost2 iscsid: received iferror -22 May 8 19:43:24 xenhost2 last message repeated 2 times May 8 19:43:24 xenhost2 iscsid: connection8:0 is operational after recovery (1 attempts) May 8 19:43:26 xenhost2 iscsid: received iferror -22 What exactly does iferror -22 mean? My system is Debian Etch 64bit running open-iscsi 2.0.865-1 from debian unstable. I am connecting to two PS400 from EqualLogic. I am running xen 3.2 from etch-backports with the block-iscsi script from http://xen.markmail.org/message/z74wb4ewxxmsyauu?q=block-iscsi . I have eth0 for LAN and eth1 for SAN on my xenhosts. I have tried enabling and disabling jumbo frames on eth1. These errors render my VMs somehow unusable. Any hints? Regards, Bjoern --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [ANNOUNCE] open-iscsi-2.0-869.1
a s p a s i a wrote: Hi Mike, In a prior version, seems like the iscsi.conf file has the values of: node.conn[0].timeo.login_timeout = 15 # To specify the time to wait for logout to complete, edit the line. # The value is in seconds and the default is 15 seconds. node.conn[0].timeo.logout_timeout = 15 # The value is in seconds and the default is 10 seconds. node.conn[0].timeo.noop_out_interval = 10 For installations using version: open-iscsi-2.0-869, would it be ok to just change the default timeout values from 5 back to 15 and 10 (respectively)? Yeah, that is fine. Why do you want to change it btw? Is it too short? Maybe the default needs to be changed? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsid: received iferror -22
Bjoern Metzdorf wrote: Hello everybody, for 2 hours now I receive LOTs of errors in my syslog: May 8 19:43:03 xenhost2 last message repeated 2 times May 8 19:43:03 xenhost2 iscsid: connection9:0 is operational after recovery (1 attempts) May 8 19:43:14 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 14:0 state (3). Dropping session. May 8 19:43:14 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 8:0 state (3). Dropping session. May 8 19:43:16 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 15:0 state (3). Dropping session. May 8 19:43:18 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 6:0 state (3). Dropping session. May 8 19:43:18 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 11:0 state (3). Dropping session. May 8 19:43:24 xenhost2 iscsid: received iferror -22 May 8 19:43:24 xenhost2 last message repeated 2 times May 8 19:43:24 xenhost2 iscsid: connection14:0 is operational after recovery (1 attempts) May 8 19:43:24 xenhost2 iscsid: received iferror -22 May 8 19:43:24 xenhost2 last message repeated 2 times May 8 19:43:24 xenhost2 iscsid: connection8:0 is operational after recovery (1 attempts) May 8 19:43:26 xenhost2 iscsid: received iferror -22 What exactly does iferror -22 mean? It just means that the kernel you are using is older than the userspace tools, so the userspace tools are trying to set a newer feature, but the kernel did not understand it. This: May 8 19:43:18 xenhost2 iscsid: Nop-out timedout after 15 seconds on connection 11:0 state (3). Dropping session. is the root problem. It means that the initiator could not reach the target for a while, so it dropped the session. My system is Debian Etch 64bit running open-iscsi 2.0.865-1 from debian unstable. I am connecting to two PS400 from EqualLogic. I am running xen 3.2 from etch-backports with the block-iscsi script from http://xen.markmail.org/message/z74wb4ewxxmsyauu?q=block-iscsi . what is the kernel version (do uname -a if you do not know). I have eth0 for LAN and eth1 for SAN on my xenhosts. I have tried enabling and disabling jumbo frames on eth1. These errors render my VMs somehow unusable. Any hints? Regards, Bjoern --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: in /var/log/messages: conn errors and recovery
aspasia wrote: Hello all, After seeing the announcement on the regression of the current release, I looked more closely into my /var/log/messages and noticed that once in a while my iscsi connections get the following: May 8 08:55:48 r05s23 kernel: connection1:0: iscsi: detected conn error (1011) May 8 08:55:49 r05s23 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) May 8 08:55:51 r05s23 iscsid: connection1:0 is operational after recovery (2 attempts) Seems like it recovers, but are these critical issues? My iscsi Are you using 869 and do you also see the nop out timeout messages or do you just see these connection error messages? device is being mounted as my root; should I increase some paramater in /etc/iscsi/iscsi.conf? Yeah, read the README section 8 for how to modify the nop and replacment timeout settings for iscsi root. Any recommendation would be greatly appreciated. A. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Should connection restored?
Konrad Rzeszutek wrote: 2). If is a EqualLogic, send a AsyncMsg telling the initiator that the block device is going to be off-line. What is this? I do not think we handle this. Is it a verndor specific async iscsi event? Yes. To be exact attached is a TCP dump, look for seq no 1774. We do try to re-login afterwards. Ah that is just target requests logout. That is standard and like you said we handle it by trying to relogin. You worried me :) I just fixed that code in 754 or something and I thought I goofed and now they did an actual vendor specific one and we had to add some more new code to handle it. 3). For others it might just terminate the connection without notifying the initiator at all. At which point the nop-ping timer (which runs by default every 15 seconds) would figure out the connection is lost, kick a retry and if that failed terminate the connection. For 1 and 3, it depends on the version of open-iscsi you are using and what the target returns on the retry if it is able to send something at all. With the current open-iscsi code, if the tcp/ip socket connect fails we continue to retry that forever or until the user manually kills it. If when we try the relogin if the target is still up and responding and responds with target not found then we will kill the connection. If we get some other errors we will continue to retry the login. I thought the re-login routine did some back-off. Like 1 second, 2 seconds, then 4 seconds and so on.. Granted the attached dump shows it to try to No we use the def time2wait we got during login negotiation. We also are a little broken and we use the time2wait returned from a logout response when we are not supposed to. re-login non-stop and maybe I am confusing it with the 2.0-868-20 which had a nop-ping code in the iSCSI daemon instead in the kernel. The nop ping code does not change the relogin behavior here. You are probably remembering linux-iscsi. It will nicely back off. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsiadm doesnt resolve hostname when used in node mode
thank you mike, but im unable to figure out how to tell ietd what to
return, but this is probably not the right place to ask anyway :)
I have another question, would it be sane/doable to have load
distribution using that ? ie dns returns diffrent ips in a round robin
fashion ? or even simple failover ?
On May 8, 6:59 pm, Mike Christie [EMAIL PROTECTED] wrote:
Maysara wrote:
Hello,
I'm usinsg iscsiadm from iscsi-initiator-utils version
6.2.0.865-0.8.el5, and i also tried opne-iscsi 2.0.730-1etch1in a line
like this:
iscsiadm -m discovery -t sendtargets -p iscsi-storage| cut -f2 -d\ |
xargs -l -I '{}' iscsiadm -m node -T {} -p iscsi-storage -l
where iscsi-storage is defined in /etc/hosts , it fails to find iscsi-
storage in the node mode, but works fine in the discovery mode, if i
change iscsi-storage to the ip of the target in the node mode, it
works fine ... i suppose this is a bug ! no ?
iscsiadm takes the values that are returned from discovery. It does not
do any hostname resolution. So if the target gives us a ip address
during discovery you have to pass iscsiadm -m node ... -l a ip address.
If the target gives us hostnames then you have to use the hostnames it
gave us.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: in /var/log/messages: conn errors and recovery
Are you using 869 and do you also see the nop out timeout messages or do you just see these connection error messages? just the above connections errors... 865 version: [EMAIL PROTECTED] ~]# iscsiadm -V iscsiadm version 2.0-865 [EMAIL PROTECTED] ~]# iscsistart -v iscsistart version 2.0-865 [EMAIL PROTECTED] ~]# modinfo scsi_transport_iscsi filename: /lib/modules/2.6.18-53.1.14.el5/kernel/drivers/scsi/scsi_transport_iscsi.ko version:2.0-865 Yeah, read the README section 8 for how to modify the nop and replacment timeout settings for iscsi root. yeah ... i'll do so .. maybe adjust and see if it reappears ... in searching through current /var/log/messages, seems like the errors only appeared twice yesterday and once this morning .. no big deal, but interesting to check. - a. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: in /var/log/messages: conn errors and recovery
a s p a s i a wrote: Are you using 869 and do you also see the nop out timeout messages or do you just see these connection error messages? just the above connections errors... 865 version: [EMAIL PROTECTED] ~]# iscsiadm -V iscsiadm version 2.0-865 [EMAIL PROTECTED] ~]# iscsistart -v iscsistart version 2.0-865 [EMAIL PROTECTED] ~]# modinfo scsi_transport_iscsi filename: /lib/modules/2.6.18-53.1.14.el5/kernel/drivers/scsi/scsi_transport_iscsi.ko version:2.0-865 Yeah, read the README section 8 for how to modify the nop and replacment timeout settings for iscsi root. yeah ... i'll do so .. maybe adjust and see if it reappears ... in searching through current /var/log/messages, seems like the errors only appeared twice yesterday and once this morning .. no big deal, but interesting to check. You want to make sure you are using 2.0-865.15 if you are using the 865 series. There was a bug in the early 865 releases where during writes we were not tracking data right and we would or the target would drop the session (you would see the error messages you posted about) to get us back on track. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
iSCSI Timeout
Are there any issues with getting rid of the iSCSI timeout? I would like my initiator to continually try to find the target device until it comes back up. I've only got one Linux System and one ISCSI device so there aren't any multi-device issues here. Thoughts? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
