iSCSI target falls asleep during "rsync" data transfer
Perseus
I'm a total iSCSI Newbie and faced the following situation which left
me clueless.
First some information about my setup and configuration:
* OpenSuSE-11.1 / Kernel 2.6.27.25-0.1-default / AMD 4600+ dual core
* iscsiadm version 2.0-870
* iSCSI target is a DroboPro with 8 TB connected to a Realtek based
Gigabit card
So far I could establish connections, the target was discovered and
after mounting
the external partitions to the local directory tree, I started some
big "rsync" runs to
copy 100s of Gigabytes of date to the DroboPro.
First, the "rsync" run as expected but after varyiig times I/O errors
occured in the
terminal where I started and watched the "rsync -va /source /
destination" run.
Soon I found out that it was not a harddisk or similar failure that
issued these
I/O error messages. They appeared obviously due to the DroboPro
putting itself
into Standby without caring for the running rsync process! My Linux
server does
recognize this and thus runs into the error messages.
As far as my limited knowledge allows, here is some diagnosis of the
current
state, ie. DroboPro is Standby and cannot be reactivated by a button
press or
cable plug-off and plug-on again (which would work with USB, btw.):
# --- 0 ---
# hwinfo --scsi
46: SCSI d00.0: 10600 Disk
[Created at block.243]
UDI: /org/freedesktop/Hal/devices/
storage_serial_36001a620000042303932313430303831
Unique ID: R5W5.4hEDkoEhZf6
SysFS ID: /class/block/sdl
SysFS BusID: 13:0:0:0
SysFS Device Link: /devices/platform/host13/session1/
target13:0:0/13:0:0:0
Hardware Class: disk
Model: "DROBO DroboPro"
Vendor: "DROBO"
Device: "DroboPro"
Revision: "1.00"
Driver: "sd"
Device File: /dev/sdl (/dev/sg13)
Device Files: /dev/sdl, /dev/disk/by-id/
scsi-36001a620000042303932313430303831, /dev/disk/by-path/
ip-192.168.179.61:3260-iscsi-iqn.
2005-06.com.datarobotics:drobopro.tdb092140081.node0-lun-0
Device Number: block 8:176-8:191 (char 21:13)
Geometry (Logical): CHS 2097151/64/32
Size: 4294967160 sectors a 512 bytes
Drive status: no medium
Config Status: cfg=new, avail=yes, need=no, active=unknown
47: SCSI d00.1: 10600 Disk
[Created at block.243]
UDI: /org/freedesktop/Hal/devices/
storage_serial_36001a620000142303932313430303831
Unique ID: uGm9.4hEDkoEhZf6
SysFS ID: /class/block/sdm
SysFS BusID: 13:0:0:1
SysFS Device Link: /devices/platform/host13/session1/
target13:0:0/13:0:0:1
Hardware Class: disk
Model: "DROBO DroboPro"
Vendor: "DROBO"
Device: "DroboPro"
Revision: "1.00"
Driver: "sd"
Device File: /dev/sdm (/dev/sg14)
Device Files: /dev/sdm, /dev/disk/by-id/
scsi-36001a620000142303932313430303831, /dev/disk/by-path/
ip-192.168.179.61:3260-iscsi-iqn.
2005-06.com.datarobotics:drobopro.tdb092140081.node0-lun-1
Device Number: block 8:192-8:207 (char 21:14)
Geometry (Logical): CHS 2097151/64/32
Size: 4294967160 sectors a 512 bytes
Drive status: no medium
Config Status: cfg=new, avail=yes, need=no, active=unknown
48: SCSI d00.2: 10600 Disk
[Created at block.243]
UDI: /org/freedesktop/Hal/devices/
storage_serial_36001a620000242303932313430303831
Unique ID: LS0E.4hEDkoEhZf6
SysFS ID: /class/block/sdn
SysFS BusID: 13:0:0:2
SysFS Device Link: /devices/platform/host13/session1/
target13:0:0/13:0:0:2
Hardware Class: disk
Model: "DROBO DroboPro"
Vendor: "DROBO"
Device: "DroboPro"
Revision: "1.00"
Driver: "sd"
Device File: /dev/sdn (/dev/sg15)
Device Files: /dev/sdn, /dev/disk/by-id/
scsi-36001a620000242303932313430303831, /dev/disk/by-path/
ip-192.168.179.61:3260-iscsi-iqn.
2005-06.com.datarobotics:drobopro.tdb092140081.node0-lun-2
Device Number: block 8:208-8:223 (char 21:15)
Geometry (Logical): CHS 2097151/64/32
Size: 4294967160 sectors a 512 bytes
Drive status: no medium
Config Status: cfg=new, avail=yes, need=no, active=unknown
# --- 1 ---
# iscsiadm -m session -P 1
Target: iqn.2005-06.com.datarobotics:drobopro.tdb092140081.node0
Current Portal: 192.168.179.61:3260,0
Persistent Portal: 192.168.179.61:3260,0
**********
Interface:
**********
Iface Name: default
Iface Transport: tcp
Iface Initiatorname: iqn.
2005-06.com.datarobotics:drobopro.tdb092140081.node0
Iface IPaddress: 192.168.179.60
Iface HWaddress: default
Iface Netdev: default
SID: 1
iSCSI Connection State: IN LOGIN
iSCSI Session State: FREE
Internal iscsid Session State: REPOEN
# --- 2 ---
# ping -c 1 192.168.179.61
PING 192.168.179.61 (192.168.179.61) 56(84) bytes of data.
64 bytes from 192.168.179.61: icmp_seq=1 ttl=64 time=0.112 ms
--- 192.168.179.61 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.112/0.112/0.112/0.000 ms
# --- 3 ---
# rcopen-iscsi status
Checking for iSCSI initiator
service: running
# --- 4 ---
# lsscsi
[13:0:0:0] disk DROBO DroboPro 1.00 /dev/sdl
[13:0:0:1] disk DROBO DroboPro 1.00 /dev/sdm
[13:0:0:2] disk DROBO DroboPro 1.00 /dev/sdn
# --- 5 ---
# mount
!!! No output for the DroboPro, should be /mnt/DroboPro1 ... /mnt/
DroboPro3 !!!
# --- 6 ---
# iscsiadm -m discovery -p 192.168.179.61:3260
discovery.startup = manual
discovery.type = sendtargets
discovery.sendtargets.address = 192.168.179.61
discovery.sendtargets.port = 3260
discovery.sendtargets.auth.authmethod = None
discovery.sendtargets.auth.username = <empty>
discovery.sendtargets.auth.password = <empty>
discovery.sendtargets.auth.username_in = <empty>
discovery.sendtargets.auth.password_in = <empty>
discovery.sendtargets.timeo.login_timeout = 15
discovery.sendtargets.reopen_max = 5
discovery.sendtargets.timeo.auth_timeout = 45
discovery.sendtargets.timeo.active_timeout = 30
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768
# --- 7 ---
I also tried to reset the device or bus:
# sg_reset -d /dev/sg15
sg_reset: starting device reset
sg_reset: requested type of reset may not be available
Final Remark:
1. I will be happy to offer more diagnosis information if you tell me
what you need and how I can supply it.
2. I'm rather sure this is not an open-iscsi error but I have hope
that this behaviour
can be fixed with the help of a sophisticated open-iscsi setup.
Any help is greatly appreciated!
Regards,
Frank
t...@clever.ms
this way, as I didn't find an alternative. The same message was
posted to the iscsi-group (Google) but it did not appear there for
whatever reason. So, out of urgent need, I try this way - sorry!
---------------------------------------------------------------------------
Hello all,
I'm a total iSCSI Newbie and faced the following situation
which left me clueless. Setup and configuration information:
* OpenSuSE-11.1 / Kernel 2.6.27.25-0.1-default / AMD 4600+ dual core
* iscsiadm version 2.0-870
* iSCSI target is a DroboPro with 8 TB connected to a Realtek based Gigabit card
So far I could establish connections, the target was discovered
and after mounting the external partitions to the local directory
tree, I started some big "rsync" runs to copy 100s of Gigabytes
of date to the DroboPro.
First, the "rsync" run as expected but after varying times
I/O errors occured in the terminal where I started and watched
the "rsync -va /source / destination" run.
Soon I found out that it was not a harddisk or similar failure
that issued these I/O error messages. They appeared obviously
due to the DroboPro putting itself into standby without caring
for the running rsync process ... to bad, I guess :-(
The Linux iSCSI initiator doesn't seem to recognize anything wrong
but the "rsync" runs blindly into these error messages.
As far as my limited knowledge allows, here is some diagnosis
of the current state, ie. DroboPro is in standby and cannot
be reactivated by a button press or cable plug-off and plug-on
again (which works good with USB, btw.):
# --- 0 ---
# hwinfo --scsi
46: SCSI d00.0: 10600 Disk
[Created at block.243]
UDI: /org/freedesktop/Hal/devices/storage_serial_36001a620000042303932313430303831
Unique ID: R5W5.4hEDkoEhZf6
SysFS ID: /class/block/sdl
SysFS BusID: 13:0:0:0
SysFS Device Link: /devices/platform/host13/session1/target13:0:0/13:0:0:0
Hardware Class: disk
Model: "DROBO DroboPro"
Vendor: "DROBO"
Device: "DroboPro"
Revision: "1.00"
Driver: "sd"
Device File: /dev/sdl (/dev/sg13)
Device Files: /dev/sdl, /dev/disk/by-id/scsi-36001a620000042303932313430303831, /dev/disk/by-path/ip-192.168.179.61:3260-iscsi-iqn.2005-06.com.datarobotics:drobopro.tdb092140081.node0-lun-0
Device Number: block 8:176-8:191 (char 21:13)
Geometry (Logical): CHS 2097151/64/32
Size: 4294967160 sectors a 512 bytes
Drive status: no medium
Config Status: cfg=new, avail=yes, need=no, active=unknown
47: SCSI d00.1: 10600 Disk
[Created at block.243]
UDI: /org/freedesktop/Hal/devices/storage_serial_36001a620000142303932313430303831
Unique ID: uGm9.4hEDkoEhZf6
SysFS ID: /class/block/sdm
SysFS BusID: 13:0:0:1
SysFS Device Link: /devices/platform/host13/session1/target13:0:0/13:0:0:1
Hardware Class: disk
Model: "DROBO DroboPro"
Vendor: "DROBO"
Device: "DroboPro"
Revision: "1.00"
Driver: "sd"
Device File: /dev/sdm (/dev/sg14)
Device Files: /dev/sdm, /dev/disk/by-id/scsi-36001a620000142303932313430303831, /dev/disk/by-path/ip-192.168.179.61:3260-iscsi-iqn.2005-06.com.datarobotics:drobopro.tdb092140081.node0-lun-1
Device Number: block 8:192-8:207 (char 21:14)
Geometry (Logical): CHS 2097151/64/32
Size: 4294967160 sectors a 512 bytes
Drive status: no medium
Config Status: cfg=new, avail=yes, need=no, active=unknown
48: SCSI d00.2: 10600 Disk
[Created at block.243]
UDI: /org/freedesktop/Hal/devices/storage_serial_36001a620000242303932313430303831
Unique ID: LS0E.4hEDkoEhZf6
SysFS ID: /class/block/sdn
SysFS BusID: 13:0:0:2
SysFS Device Link: /devices/platform/host13/session1/target13:0:0/13:0:0:2
Hardware Class: disk
Model: "DROBO DroboPro"
Vendor: "DROBO"
Device: "DroboPro"
Revision: "1.00"
Driver: "sd"
Device File: /dev/sdn (/dev/sg15)
Device Files: /dev/sdn, /dev/disk/by-id/scsi-36001a620000242303932313430303831, /dev/disk/by-path/ip-192.168.179.61:3260-iscsi-iqn.2005-06.com.datarobotics:drobopro.tdb092140081.node0-lun-2
Remarks
-------
Mike Christie
> Soon I found out that it was not a harddisk or similar failure that
> issued these
> I/O error messages. They appeared obviously due to the DroboPro
> putting itself
> into Standby without caring for the running rsync process! My Linux
> server does
> recognize this and thus runs into the error messages.
>
Weird! I have not seen a problem like this before.
The initiator is trying login. If you are sure the target is going into
a standby mode when it should not, maybe it is best to contact the
target vendor.