Michael Kindermann wrote:
> Hello,
> thanks for quick reply. During weekend I did backups on the iscsi-device
> with not one single error on kernel 2.6.22. 
> Am Freitag, den 13.06.2008, 19:11 +0200 schrieb Mike Christie:
>> Michael Kindermann wrote:
>>> Hello,
>>> We receive errors below on a standard debian lenny/testing sytem since
>> kernelupdate from 2.6.22-3-686 to latest debian-kernel 2.6.24-3-686. The
>> iscsi-device is Eonstore E16A-2130.
>>> The open-iscsi deb package is 2.0.869.2-2. When we use the older kernel
>> the errors disappear. Errors only happen during copying on the
>> iscsi-devices.
>>> Is this behaviour a debian specific problem and I have to compile
>> open-scsi?   
>>> Jun 13 14:32:30 hg2 kernel:  connection1:0: iscsi: detected conn error
>> (1011)
>>> Jun 13 14:32:31 hg2 iscsid: Kernel reported iSCSI connection 1:0 error
>> (1011) state (3)
>>> Jun 13 14:32:41 hg2 kernel: iscsi: host reset succeeded
>> The READs or WRITEs from the copy operations are timing out. The SCSI 
>> layer sets a timer on each command which is probably the default of 60 
>> seconds (scsi layer sets to 30 and udev normal raises this to 60). If 
>> the command does not complete in that time it starts the scsi error 
>> handler and you end up getting these errors in the worst case where we 
>> cannot just abort and restart the command or reset the device.
>> Are you copying to the iscsi device or from it (and are you then copying 
>> to to/from a non-iscsi device), or is it mixed?
> These errors posted earlier resulting from simply copying a dvdimage
> from a local logical volume on SATA-Drives to a logical volume on the
> iscsi-device. Normal usage is to do backups by rsync (dirvish) to this
> device, which are very slow due to timeouts (normal rsync linux backups
> via ssh and the windows-filesystems by local rsyncing cifs-mounts).
> Results stay the same. The errors only happen when copying to the
> iscsi-device. Restoring of data from iscsi to local volumes works great
> without errors on the 2.6.24 -Kernel.   

Weird. We actually fixed a write bug in that kernel, so writes should be 
better. Maybe we are now overloading the target - I do not know.

If this happens again you might want to lower the queue depths by 
setting the following values lowwer


Are you doing IO to lots of disks at the same time? And what type of 
target is this? Does it have good backing storage - fast sas or scsi 
disk or slower ide or sata ones?

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

Reply via email to