bigcatxjs wrote:
>>> Mar 17 18:27:59 MYHOST53 kernel: scsi 2:0:0:0: rejecting I/O to dead
>>> device
>> It looks like one of the following is happening:
>>
>> 1. were using RHEL 5.2 and the target logged us out or dropped the
>> session and when we tried to login we got what we thought was a fatal
>> error (but may be a transient error) from the target so iscsid destroyed
>> the session. When this happens the devices will be removed and IO to the
>> device will get failed like you see below with the rejecting to dead device.
>>
>> In RHEL 5.3 this should be fixed. We will retry the login error instead
>> of giving up right away.
>>
>> 2. someone ran a iscsiadm logout command.
>
> Unlikely, I am the only person working with this host currently.
>
>> 3. iscsid bugged out and killed the session. I do not think this happens
>> because I see below for the session4 (connection4:0) we get an error and
>> end up logging back in so iscsid is up and running.
>
> Yes - iscsidm -m session -P3 showed ISCSI as running. BUT the device
> SDC1;
> /dev/sdc1 /sandisk1 ext3
> _netdev 0 0
>
> It disappeared! in /DEV the SDC re-appeared as SDD!! So I needed to
> update our FSTAB to
> /dev/sdd1 /sandisk1 ext3
> _netdev 0 0
Did this happen automatically. So the reject messages appeared then you
saw sdc switch to sdd? Or did you run some iscsiadm command after you
saw the reject messages?
Did this happen the time you sent the log output for?
In the log out put you got sdd here:
> > Mar 17 12:40:47 MYHOST53 kernel: sdd: Write Protect is off
> > Mar 17 12:40:47 MYHOST53 kernel: SCSI device sdd: drive cache: write
> > back w/ FUA
Was this where sdd got added after it was sdc?
Was sdc this disk:
Mar 17 18:27:59 MYHOST53 kernel: scsi 2:0:0:0: rejecting I/O to dead
device
The thing is that 2:0:0:0 is on a completely different
host/session/connection than sdd.
In the original mail you only had one session running on the rhel 5.3 box:
iscsiadm;
iSCSI Transport Class version 2.0-724
iscsiadm version 2.0-868
Target: iqn.2000-08.com.datacore:sm2-3
Current Portal: 172.16.200.9:3260,1
Persistent Portal: 172.16.200.9:3260,1
**********
Interface:
**********
Iface Name: default
Iface Transport: tcp
Iface Initiatorname: iqn.2005-03.com.redhat:01.406e5fd710e2
Iface IPaddress: 172.16.200.69
Iface HWaddress: default
Iface Netdev: default
SID: 1
iSCSI Connection State: LOGGED IN
iSCSI Session State: Unknown
Internal iscsid Session State: NO CHANGE
************************
Negotiated iSCSI params:
************************
HeaderDigest: None
DataDigest: None
MaxRecvDataSegmentLength: 131072
MaxXmitDataSegmentLength: 262144
FirstBurstLength: 0
MaxBurstLength: 1048576
ImmediateData: No
InitialR2T: Yes
MaxOutstandingR2T: 1
************************
Attached SCSI devices:
************************
Host Number: 2 State: running
scsi2 Channel 00 Id 0 Lun: 0
Attached scsi disk sdc State: running
is that still the same?
In general disks can get any name from restart to restart of the iscsi
service. So during one boot you will get sda and then when you reboot
that disk might now be sdb. You should use labels or udev names.
For iscsi you normally do not want to use sdX names because we do our
login and scanning asynchronously, so the sdX names are pretty random.
--~--~---------~--~----~------------~-------~--~----~
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
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
