Accessing specific lun in target with open-e
Hello all, I am using open-e DSS storage (http://open-e.com). I usually have 1 lun per target, but for backup purposes, I take snapshots for each lun. This snapshot then becomes a part of the parent LUN target, so that TargetX has LunA and LunS (snapshot). When I login to the target, however, I see only one LUN. I have a udev rule that create a symlink as /dev/iscsi_XX-. I see the main lun of the target, but not the snapshot. After resetting the open-e iscsi connections (sort of IETd implementation), and rescanning the target on my initiator, a P 3 listing says this: Target: iqn.2008-02:open-e-1.rt Current Portal: 172.17.77.12:3260,1 Persistent Portal: 172.17.77.12:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface IPaddress: 172.17.77.51 Iface HWaddress: default Iface Netdev: default SID: 261 iSCSI Connection State: LOGGED IN Internal iscsid Session State: NO CHANGE Negotiated iSCSI params: HeaderDigest: None DataDigest: None MaxRecvDataSegmentLength: 131072 MaxXmitDataSegmentLength: 8192 FirstBurstLength: 65536 MaxBurstLength: 262144 ImmediateData: No InitialR2T: Yes MaxOutstandingR2T: 1 Attached SCSI devices: Host Number: 262State: running scsi262 Channel 00 Id 0 Lun: 3 Attached scsi disk sds State: running Nothing said about the snapshot. Anyone has an idea? Would that be a specific to open-e dss storage? Thank you for any suggestions. fred --~--~-~--~~~---~--~~ 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 initiator lockup
Hello,
Due to resetting an iSCSI target (SCST) while an iSCSI session was
active, the iSCSI initiator seems to be locked up. E.g. when I try to
run the command iscsiadm -m session or iscsiadm ... --logout,
these command hangs forever. This is probably not the intended
behavior ?
# cat /etc/issue
Ubuntu 7.10 \n \l
# uname -a
Linux INF010 2.6.24 #1 SMP Thu Feb 7 15:45:15 CET 2008 x86_64 GNU/Linux
# dpkg -l open-iscsi
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name VersionDescription
+++-==-==-
ii open-iscsi 2.0.865-1 High performance, transport independent iSCS
# pidof iscsid
4787 4786
# strace iscsiadm -m session
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, [EMAIL PROTECTED], 110) = 0
write(3, \10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
4760) = 4760
recvfrom(3, unfinished ...
# strace iscsiadm -m node -p 192.168.64.13 -T ... --logout
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, [EMAIL PROTECTED], 110) = 0
write(3, \10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
4760) = 4760
recvfrom(3, unfinished ...
Kernel messages:
May 7 11:34:20 INF010 kernel: [0.00] scsi28 : iSCSI Initiator
over TCP/IP
May 7 11:34:20 INF010 kernel: [0.00] scsi 28:0:0:0:
Direct-Access SCST_FIO vdisk0096 PQ: 0 ANSI: 4
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Very
big device. Trying to use READ CAPACITY(16).
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
6778558976 512-byte hardware sectors (3470622 MB)
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Write
Protect is off
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Mode
Sense: 6b 00 10 08
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Write
cache: enabled, read cache: enabled, supports DPO and FUA
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Very
big device. Trying to use READ CAPACITY(16).
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
6778558976 512-byte hardware sectors (3470622 MB)
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Write
Protect is off
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Mode
Sense: 6b 00 10 08
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde] Write
cache: enabled, read cache: enabled, supports DPO and FUA
May 7 11:34:20 INF010 kernel: [0.00] sde: unknown partition table
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
Attached SCSI disk
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:0: Attached
scsi generic sg5 type 0
May 7 11:34:20 INF010 kernel: [0.00] scsi 28:0:0:1:
Direct-Access SCST_FIO vdisk1096 PQ: 0 ANSI: 4
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Very
big device. Trying to use READ CAPACITY(16).
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
6778558976 512-byte hardware sectors (3470622 MB)
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Write
Protect is off
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Mode
Sense: 6b 00 10 08
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Write
cache: enabled, read cache: enabled, supports DPO and FUA
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Very
big device. Trying to use READ CAPACITY(16).
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
6778558976 512-byte hardware sectors (3470622 MB)
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Write
Protect is off
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Mode
Sense: 6b 00 10 08
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf] Write
cache: enabled, read cache: enabled, supports DPO and FUA
May 7 11:34:20 INF010 kernel: [0.00] sdf: unknown partition table
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
Attached SCSI disk
May 7 11:34:20 INF010 kernel: [0.00] sd 28:0:0:1: Attached
scsi generic sg6 type 0
May 7 11:34:27 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
Synchronizing SCSI cache
May 7 11:34:27 INF010 kernel: [0.00] iscsi: cmd 0x35 is not queued (6)
May 7 11:34:27 INF010 last message repeated 2 times
May 7 11:34:27 INF010 kernel: [0.00] sd 28:0:0:0: [sde]
Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
May 7 11:34:27 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
Synchronizing SCSI cache
May 7 11:34:27 INF010 kernel: [0.00] iscsi: cmd 0x35 is not queued (6)
May 7 11:34:27 INF010 last message repeated 2 times
May 7 11:34:27 INF010 kernel: [0.00] sd 28:0:0:1: [sdf]
Re: in /var/log/messages: conn errors and recovery
Hi Mike, using the Wasabi target and the latest open-iscsi git version (as of today) I still get the errors, which are according to the Wasabi log a time out problem. It only happens when logging in, which used to take about one second or less, but now 5-10 seconds. The messages log on the initiator shows this: scsi6 : iSCSI Initiator over TCP/IP connection1:0: detected conn error (1011) connection1:0: detected conn error (1011) connection1:0: detected conn error (1011) connection1:0: detected conn error (1011) scsi scan: 66 byte inquiry failed. Consider BLIST_INQUIRY_36 for this device scsi 6:0:0:0: Direct-Access Wasabi WSB/iSCSI0401 PQ: 0 ANSI: 5 sd 6:0:0:0: [sdb] 32768 512-byte hardware sectors (167772 MB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 5b 00 00 08 sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 6:0:0:0: [sdb] 32768 512-byte hardware sectors (167772 MB) sd 6:0:0:0: [sdb] Write Protect is off sd 6:0:0:0: [sdb] Mode Sense: 5b 00 00 08 sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 6:0:0:0: [sdb] Attached SCSI disk sd 6:0:0:0: Attached scsi generic sg2 type 0 Albert On May 8, 11:46 pm, Mike Christie [EMAIL PROTECTED] wrote: 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 -~--~~~~--~~--~--~---
Re: Should connection restored?
Hello All, 1. I am using latest iscsitarget-0.4.16-1 from sourceforge. Now,can you tell whether it is expected to retain the connection with initiator once the target is restarted? - 2. You wrote. The reason for having you do iscsid -d 8 was so we could see why we cannot log back in iscsid -d 8 log messages can be seen from dmesg...right? check 2nd last line here in dmesg.connection13:0: iscsi: detected conn error (1011) --- iscsi: cmd 0x28 is not queued (7) iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 8 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 835576 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 835576 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 iscsi: cmd 0x28 is not queued (7) iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 8 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 16 sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 scsi14 : iSCSI Initiator over TCP/IP Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdh: 1048576 512-byte hdwr sectors (537 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through SCSI device sdh: 1048576 512-byte hdwr sectors (537 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through sdh: sdh1 sd 14:0:0:0: Attached scsi disk sdh sd 14:0:0:0: Attached scsi generic sg6 type 0 Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdi: 835584 512-byte hdwr sectors (428 MB) sdi: Write Protect is off sdi: Mode Sense: 77 00 00 08 SCSI device sdi: drive cache: write through SCSI device sdi: 835584 512-byte hdwr sectors (428 MB) sdi: Write Protect is off sdi: Mode Sense: 77 00 00 08 SCSI device sdi: drive cache: write through sdi: sdi1 sd 14:0:0:1: Attached scsi disk sdi sd 14:0:0:1: Attached scsi generic sg7 type 0 connection13:0: iscsi: detected conn error (1011) session13: iscsi: session recovery timed out after 120 secs --- 3. when session is recovered. [EMAIL PROTECTED] iscsi]# iscsiadm -m session -P 3 iSCSI Transport Class version 1.1-646 iscsiadm version 2.0-865 Target: iqn.2008-04.com.qualexsystems:Tar1 Current Portal: 192.168.7.173:3260,1 Persistent Portal: 192.168.7.173:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface IPaddress: default Iface HWaddress: default Iface Netdev: default SID: 13 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: 14 State: running scsi14 Channel 00 Id 0 Lun: 0 Attached scsi disk sdh State: running scsi14 Channel 00 Id 0 Lun: 1 Attached scsi disk sdi State: running Though Disk state is running,still iSCSI Connection State: IN LOGIN. So disks still becomes unusable. Conclusion: What is moral of the story i
Persistent connection problem
Hello All, 1. I am using latest iscsitarget-0.4.16-1 from sourceforge. Now,can you tell whether it is expected to retain the connection with initiator once the target is restarted? - 2. You wrote. The reason for having you do iscsid -d 8 was so we could see why we cannot log back in iscsid -d 8 log messages can be seen from dmesg...right? check 2nd last line here in dmesg.connection13:0: iscsi: detected conn error (1011) --- iscsi: cmd 0x28 is not queued (7) iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 8 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 835576 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 835576 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 iscsi: cmd 0x28 is not queued (7) iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 8 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 16 sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 iscsi: cmd 0x28 is not queued (7) sd 14:0:0:1: SCSI error: return code = 0x0001 end_request: I/O error, dev sdi, sector 0 scsi14 : iSCSI Initiator over TCP/IP - Hide quoted text - - Show quoted text - Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdh: 1048576 512-byte hdwr sectors (537 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through SCSI device sdh: 1048576 512-byte hdwr sectors (537 MB) sdh: Write Protect is off sdh: Mode Sense: 77 00 00 08 SCSI device sdh: drive cache: write through sdh: sdh1 sd 14:0:0:0: Attached scsi disk sdh sd 14:0:0:0: Attached scsi generic sg6 type 0 Vendor: IET Model: VIRTUAL-DISK Rev: 0 Type: Direct-Access ANSI SCSI revision: 04 SCSI device sdi: 835584 512-byte hdwr sectors (428 MB) sdi: Write Protect is off sdi: Mode Sense: 77 00 00 08 SCSI device sdi: drive cache: write through SCSI device sdi: 835584 512-byte hdwr sectors (428 MB) sdi: Write Protect is off sdi: Mode Sense: 77 00 00 08 SCSI device sdi: drive cache: write through sdi: sdi1 sd 14:0:0:1: Attached scsi disk sdi sd 14:0:0:1: Attached scsi generic sg7 type 0 connection13:0: iscsi: detected conn error (1011) session13: iscsi: session recovery timed out after 120 secs --- 3. when session is recovered. [EMAIL PROTECTED] iscsi]# iscsiadm -m session -P 3 iSCSI Transport Class version 1.1-646 iscsiadm version 2.0-865 Target: iqn.2008-04.com.qualexsystems:Tar1 Current Portal: 192.168.7.173:3260,1 Persistent Portal: 192.168.7.173:3260,1 ** Interface: ** Iface Name: default Iface Transport: tcp Iface IPaddress: default Iface HWaddress: default Iface Netdev: default SID: 13 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: 14 State: running scsi14 Channel 00 Id 0 Lun: 0 Attached scsi disk sdh State: running scsi14 Channel 00 Id 0 Lun: 1 Attached scsi disk sdi State: running Though Disk state is running,still iSCSI Connection State: IN LOGIN. So disks still becomes unusable.
Re: iscsid: received iferror -22
Hi Mike, 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. Ok. No no big problems here. 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. I really need holidays. The problem was home-made and I was totally blind yesterday evening: A simple plain old annoying ip conflict on my SAN nics was causing these problems. 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). For completeness: Linux xenhost2 2.6.18-6-xen-amd64 #1 SMP Thu Apr 24 05:10:26 UTC 2008 x86_64 GNU/Linux The systems are running fine now again! Thanks anyway for the help! 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: Accessing specific lun in target with open-e
Attached scsi disk sds State: running Nothing said about the snapshot. Anyone has an idea? Would that be a specific to open-e dss storage? What does #sg_luns /dev/sds give you? (sg_luns is part of sg3_utils package). --~--~-~--~~~---~--~~ 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 Fri, May 09, 2008 at 02:36:25AM -0700, MAKHU wrote: Hello All, 1. I am using latest iscsitarget-0.4.16-1 from sourceforge. And an older version of Open-iSCSI..would say 868-20. Have you tried using the one that got released about a week ago? ... snip ... Host Number: 14 State: running scsi14 Channel 00 Id 0 Lun: 0 Attached scsi disk sdh State: running scsi14 Channel 00 Id 0 Lun: 1 Attached scsi disk sdi State: running Though Disk state is running,still iSCSI Connection State: IN LOGIN. So disks still becomes unusable. Are the disks really unusable? What happens when you do 'dd if=/dev/sdh of=/dev/null count=1' ? --~--~-~--~~~---~--~~ 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: Accessing specific lun in target with open-e
Fred Blaise wrote: Hello all, I am using open-e DSS storage (http://open-e.com). I usually have 1 lun per target, but for backup purposes, I take snapshots for each lun. This snapshot then becomes a part of the parent LUN target, so that TargetX has LunA and LunS (snapshot). When I login to the target, however, I see only one LUN. I have a udev rule that create a symlink as /dev/iscsi_XX-. I see the main lun of the target, but not the snapshot. After resetting the open-e iscsi connections (sort of IETd implementation), and rescanning the target on my initiator, a P 3 listing says this: Are you rescanning the target with iscsiadm or by hand? --~--~-~--~~~---~--~~ 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?
MAKHU wrote: Conclusion: What is moral of the story i got is that in our target- initiator pair,Persistent connection is not possible.After target/ Initiator iscsi-target daemon restart(code given below),connection is lost causing disks to be unusable. What you should have taken from the mails was that you should either: 1. Spring for an extra nic on the target and use multipath and set queue_if_no_path or no_path_retry queue. 2. set the iscsi node.session.timeo.replacement_timeout timer very high. --~--~-~--~~~---~--~~ 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: replacement_timeout (disadvantages of increasing)
[EMAIL PROTECTED] wrote: Hi, What are the disadvantages of increasing the replacement_timeout to large values? If you use multipath you want this value short. If you do not use multipath you want this longer. See the README on open-iscsi.org for how to tune. The non-multipath case and the iscsi root are similar. Are there alternate ways to prevent a device from going into RO mode during intermittent network failures? Use dm-multipath. Using multipath is the best way to handle this problem. If your target has two ports or you are using a software target and the box has multiple nics use them and do multipath. --~--~-~--~~~---~--~~ 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
I need more to the log. The parts above this would tell me what happened. OK, I will capture complete console log next time, sorry, but I rebooted the couple of test boxes that had this node.session.timeo.replacement_timeout = 172800 node.conn[0].timeo.noop_out_timeout = 0 node.conn[0].timeo.noop_out_interval = 0 OK! will do and observe - I just updated the /etc/iscsi/iscsi.conf file and rebooted (working on my golden-build server) ... I also downloaded the latest stable release from the open-iscsi.org site, so that it is now on the 869.2 version as opposed to 865 ... will observe and see if any strange behaviours occur. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
