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

node.session.cmds_max
node.session.queue_depth

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