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
-~----------~----~----~----~------~----~------~--~---
