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,
# 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,
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]
Result: hostbyte=DID_
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.
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
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: in /var/log/messages: conn errors and recovery
[EMAIL PROTECTED] wrote: > 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 It looks like it is not liking the inquiry command the scsi layer sends it. Do you see anything about bad/invalid scsi commands or something about INQRUIYs in the log? What kernel are you using? I thought from the beginning of the thread you were using 2.6.18-53.1.14.el. Is that right? > 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: iSCSI Timeout
An Oneironaut wrote: > 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? Yeah, you can turn up replacement timeout very high and turn off the nop timers if you wanted to. See the README. If you have multiple portals on the target though you probably just want to use dm-multipath with iscsi and set queue_if_no_path or "no_path_retry queue" in the mutlipath.conf file. --~--~-~--~~~---~--~~ 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: iSCSI initiator lockup
Bart Van Assche wrote: > 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 > This is the same issue as the "Kernel bug during logout" issue :) The scsi-ml sysfs userspace behavior changed. It broke iscsiadm blah blah. You have to either use 2.6.25, or use the kernel modules and tools in the open-iscsi-2.0-869.2.tar.gz release on open-iscsi.org. --~--~-~--~~~---~--~~ 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: in /var/log/messages: conn errors and recovery
Hi Mike, the last issue is reported by another person - albert, I initiated this thread, I think we are getting similar symptoms/errors: > What kernel are you using? I thought from the beginning of the thread > you were using 2.6.18-53.1.14.el. Is that right? Yes, that is right - that is the original thread - one of my iscsi hosts, which I have deployed into about 50 machines is running that above kernel - Centos 5.1; and as we exchanged info earlier, it is running the following version of open-iscsi: uname -a Linux r04s25 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5 11:37:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux [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 -- In the last 2 days, I have deployed this iscsiRoot into about 50 machines, where a few test/QA folks commenced testing on them. During use ... they have noticed various symptoms such as: 1. Root FileSystem becomes inaccessible, where one is unable to perform any further work; networking seems to be ok (ping'able from the outside) but the session is stuck; Meanwhile at the console, we see the following messages: scsi 6:0:0:0 rejecting I/O to dead device EXT3-fs error (device sde1) Upon restarting the box, the iscsiRoot mounted fine and seems like it is ok again. 2. This morning I checked the 3 other servers we left to observe and noticed I am unable to ssh into the box (ssh connection is denied), I walked over to check the console of one of the hosts the FS root is still there, I can ls and cd into various directories, but when I try to run a command such as "df" or "cat" to check the /var/log/messages file for instance I get the following error: iscsi: cmd 0x28 is not queued (8) end_request: I/O error, dev sde sector 3389502 -bash: /bin/df: Input/output error. .. These issues I observed on the hosts that are actually being used (running application tests, etc.) ... Another same box (my golden image) booted iscsiroot on same OS and open-iscsi version does not have problems, but it's not doing anything I know we discussed that I should upgrade ... should I upgrade to the current stable release? Before I do, I'd like to know if the above are known errors and why? thanks in advance, A. > > -- A S P A S I 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 -~--~~~~--~~--~--~---
replacement_timeout (disadvantages of increasing)
Hi, What are the disadvantages of increasing the replacement_timeout to large values? Are there alternate ways to prevent a device from going into RO mode during intermittent network failures? Thanks, Luke. --~--~-~--~~~---~--~~ 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: > Hi Mike, > > the last issue is reported by another person - albert, I initiated > this thread, I think we are getting similar symptoms/errors: > >> What kernel are you using? I thought from the beginning of the thread >> you were using 2.6.18-53.1.14.el. Is that right? > > Yes, that is right - that is the original thread - one of my iscsi > hosts, which I have deployed into about 50 machines is running that > above kernel - Centos 5.1; and as we exchanged info earlier, it is > running the following version of open-iscsi: > uname -a > Linux r04s25 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5 11:37:38 EST 2008 > x86_64 x86_64 x86_64 GNU/Linux > [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 > > -- > > In the last 2 days, I have deployed this iscsiRoot into about 50 > machines, where a few test/QA folks commenced testing on them. During > use ... they have noticed various symptoms such as: > > 1. Root FileSystem becomes inaccessible, where one is unable to > perform any further work; networking seems to be ok (ping'able from > the outside) but the session is stuck; Meanwhile at the console, we > see the following messages: > > scsi 6:0:0:0 rejecting I/O to dead device > EXT3-fs error (device sde1) I need more to the log. The parts above this would tell me what happened. > > Upon restarting the box, the iscsiRoot mounted fine and seems like it > is ok again. > > 2. This morning I checked the 3 other servers we left to observe and > noticed I am unable to ssh into the box (ssh connection is denied), I > walked over to check the console of one of the hosts the FS root is > still there, I can ls and cd into various directories, but when I try > to run a command such as "df" or "cat" to check the /var/log/messages > file for instance I get the following error: > > iscsi: cmd 0x28 is not queued (8) > end_request: I/O error, dev sde sector 3389502 > -bash: /bin/df: Input/output error. > > .. > > These issues I observed on the hosts that are actually being used > (running application tests, etc.) ... Another same box (my golden > image) booted iscsiroot on same OS and open-iscsi version does not > have problems, but it's not doing anything > > I know we discussed that I should upgrade ... should I upgrade to the > current stable release? Before I do, I'd like to know if the above > are known errors and why? > Are you doing iscsi root for all boxes? If you are and you are using Centos 5.1 then I would use iscsi with multipath. I would use iscsi + multipath in general for all OSes and setups actually. I do not think iscsi root + multipath is supported out of the box in 5.1 so if that is not an option I would use the following settings: node.session.timeo.replacement_timeout = 172800 node.conn[0].timeo.noop_out_timeout = 0 node.conn[0].timeo.noop_out_interval = 0 for the root session. You should set that in the node db for the session that will be run as root. If you are logged into the box and the session is running then do: iscsiadm -m session -r $sid -o update -n node.session.timeo.replacement_timeout -v 172800 $sid is the session id that you would see when you run iscsiadm -m session -P 1 Then repeat this for each value and setting above. If the session is not running then pass the target and portal info for the portal that gets logged in for root. iscsiadm -m node -T target -p ip:port -o update -n node.session.timeo.replacement_timeout -v 172800 then repeat for the other values. In either case the values will be used on the next reboot (or really when the iscsi service is restarted but if you are running root we will not restart the service or it will disrupt the root disk). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
