Mike Christie schrieb: > The scsi layer sets a timeout on each command. If it does not execute in > X seconds, it will run the iscsi eh. > > So you can increase the scsi command time: > > To modify the udev rule open /etc/udev/rules.d/50-udev.rules, and find the > following lines: > > ACTION=="add", SUBSYSTEM=="scsi" , SYSFS{type}=="0|7|14", \ > RUN+="/bin/sh -c 'echo 60 > /sys$$DEVPATH/timeout'" > > > and you probably want to decrease the number of oustanding commands by > setting the node.session.cmds_max for that session. With 50 kB/s you > might as well set this to 1 command.
This helps a bit, but after some time, something weird happens. I increased the timeout to 240 seconds. The data flows fine for some time, but after a couple of minutes, every program running on that initiator machine seems to freeze (i.e. "ping" stops to ping, "top" stops to refresh the data, they can't be interrupted / won't exit with ctrl+c). There is no traffic any more between the target and the initiator. The machine is "a bit" alive, as it replies to pings and responds to sysrq magic, and I can switch VTs (ctrl+alt+F1...). The machine has its root filesystem accessible via iSCSI (via fast LAN, to a different target) which can somehow contribute to the problem? It runs a 2.6.22 kernel. Some bad interaction if the initiator is connected to two targets with different IPs, and connection to one target is very slow? No such phenomenon on a machine with rootfs on SATA, where everything works fine. -- Tomasz Chmielewski http://wpkg.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---