Matthew Dickinson wrote: > On 11/6/09 3:39 PM, "Matthew Dickinson" <matt-openis...@alpha345.com> wrote: > >> >>> Try disabling nops by setting >>> >>> node.conn[0].timeo.noop_out_interval = 0 >>> node.conn[0].timeo.noop_out_timeout = 0 > > I'm still getting errors: > > Nov 10 09:08:04 backup kernel: connection12:0: detected conn error (1011) > Nov 10 09:08:05 backup iscsid: Kernel reported iSCSI connection 12:0 error > (1011) state (3) > Nov 10 09:08:08 backup iscsid: connection12:0 is operational after recovery > (1 attempts) > Nov 10 09:09:43 backup kernel: connection11:0: detected conn error (1011) > Nov 10 09:09:43 backup kernel: connection12:0: detected conn error (1011) > Nov 10 09:09:44 backup kernel: connection11:0: detected conn error (1011) > Nov 10 09:09:44 backup iscsid: Kernel reported iSCSI connection 11:0 error > (1011) state (3) > Nov 10 09:09:44 backup iscsid: Kernel reported iSCSI connection 12:0 error > (1011) state (3) > Nov 10 09:09:44 backup iscsid: Kernel reported iSCSI connection 11:0 error > (1011) state (1) > Nov 10 09:09:46 backup kernel: session11: target reset succeeded\ > Nov 10 09:09:47 backup iscsid: connection11:0 is operational after recovery > (1 attempts) > Nov 10 09:09:47 backup iscsid: connection12:0 is operational after recovery > (1 attempts) > Nov 10 09:09:56 backup kernel: sd 18:0:0:2: SCSI error: return code = > 0x000e0000 > Nov 10 09:09:56 backup kernel: end_request: I/O error, dev sdv, sector > 60721248 > Nov 10 09:09:56 backup kernel: device-mapper: multipath: Failing path 65:80. > Nov 10 09:09:56 backup kernel: sd 18:0:0:2: SCSI error: return code = > 0x000e0000 > Nov 10 09:09:56 backup kernel: end_request: I/O error, dev sdv, sector > 60727648 > Nov 10 09:09:56 backup kernel: sd 18:0:0:2: SCSI error: return code = > 0x000e0000 > Nov 10 09:10:31 backup kernel: device-mapper: multipath: Failing path > 65:112. > > Interestingly, I tried a Windows 2008 server R2 talking over a single > connection to the storage unit, configured to access just via one > interface, I was able to sustain 20MB/s so it would ³appear² to be a > Linux-related issue - I'm only able to get 9MB/s out of Linux even when > using 8 interfaces on both controllers. >
What version of open-iscsi were you using and what kernel, and were you using the iscsi kernel modules with open-iscsi.org tarball or from the kernel? It looks like we are sending more IO than the target can handle. In one of those cases it took more than 30 or 60 seconds (depending on your timeout value). What is the value of cat /sys/block/sdXYZ/device/timeout ? If it is 30 or 60 could you increase it to 360? After you login to the target do echo 360 > /sys/block/sdXYZ/device/timeout And what is the value of: iscsiadm -m node -T your_target | grep node.session.cmds_max If that is 128, then could you decrease that to 32 or 16? Run iscsiadm -m node -T your_target -u iscsiadm -m node -T your_target -o update -n node.session.cmds_max -v 32 iscsiad-m node -T your_target -l And if those prevent the io errors then could you do echo noop > /sys/block/sdXYZ/queue/scheduler to see if performance increases with a difference scheduler. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
