>>> Sean S <sstra...@gmail.com> schrieb am 13.07.2010 um 20:41 in Nachricht <1f2389e7-9717-4f82-a05c-671f36a4c...@x21g2000yqa.googlegroups.com>: > I'm running an iscsi root partition for a CentOS machine running a > 2.6.18-53 kernel. Every couple of days I get the error: > > connection1:0 detected conn error (1011) > session1: session recovery timed out after 400 sec
Hi! I cannot answer your question, but that brings up something I wanted to talk about. Please apologize if something already exists, but I don't know: In HP-UX 11.31 you can print "scan times" per device (i.e. LUN). Here's an example for a true FC-SAN: Class I H/W Path ms_scan_time =============================== lunpath 3 0/3/1/0.0x50001fe1500c1f28.0x0 0 min 0 sec 13 ms lunpath 24 0/3/1/0.0x50001fe1500c1f28.0x4001000000000000 0 min 0 sec 88 ms lunpath 73 0/3/1/0.0x50001fe1500c1f28.0x4002000000000000 0 min 0 sec 88 ms lunpath 25 0/3/1/0.0x50001fe1500c1f28.0x4003000000000000 0 min 0 sec 88 ms lunpath 74 0/3/1/0.0x50001fe1500c1f28.0x4009000000000000 0 min 0 sec 88 ms lunpath 26 0/3/1/0.0x50001fe1500c1f28.0x4033000000000000 0 min 0 sec 88 ms lunpath 88 0/3/1/0.0x50001fe1500c1f28.0x4037000000000000 0 min 0 sec 88 ms lunpath 79 0/3/1/0.0x50001fe1500c1f28.0x403d000000000000 0 min 0 sec 91 ms lunpath 27 0/3/1/0.0x50001fe1500c1f28.0x4047000000000000 0 min 0 sec 91 ms [...] lunpath 63 0/7/1/0.0x500308c001d83803.0x4001000000000000 0 min 0 sec 11 ms lunpath 64 0/7/1/0.0x500308c001d83803.0x4002000000000000 0 min 0 sec 11 ms lunpath 65 0/7/1/0.0x500308c001d83803.0x4003000000000000 0 min 0 sec 11 ms lunpath 66 0/7/1/0.0x500308c001d83803.0x4004000000000000 0 min 0 sec 536 ms If Linux/open-iscsi had something similar, one could periodically watch the times to find bottlenecks. AFAIK, the "scan time" in HP-UX is the round-trip delay for querying a LUN or a controller (a target?). Ulrich > > I compiled the open-iscsi 2.0-871 user tools and kernel modules from > source obtained from open-iscsi.org. I custom packaged the initrd to > contain the iscsistart binary and the kernel modules from v871. I've > zeroed out the noop timeout setting and the noop interval. > > The disconnect is not reproducible, but does occur at random about > every other day. I'm assuming that the target (IET 1.4.19) is not the > issue as a second system that is using the target as an iscsi-root > drive continues to work correctly. What things should I be looking at? > I'm really struggling to understand why this happens, any suggestions > would be greatly appreciated. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@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?hl=en.
