Around a 1 1/2 years ago I heard similar reports of the Solaris initiator and Overland having poor performance. I believe there was a bug fix or setting change that resolved the problem. Unfortunately, I can't remember the solution at this point.
Are these the only error messages you see during this time period? "transport failed: reason 'tran_err': giving up" Its hard to get a sense of the frequency of these messages are they flooding your log? In respect to the Solaris initiator the tran_err message being reported by sd/ssd typically means that the initiator connection between the target and the initiator has been disconnected. Typically you would see this message along with another iscsi message like protocol error, timeout, etc. Based on your report I don't see that message. If you are seeing straight tran_errs then I would suggest the best way to isolate the problem is with a snoop trace across a couple of these tran_err messages. With this trace Sun support (or you could post it here somehow) should be able to find the FIN(TCP Disconnect) / SYN (TCP Connect) and search backwards for the source of the disconnect. Something has to be going wrong. The other approach is to trace the iSCSI session and connection states. This is pretty simple to do with dtrace. Although this approach likely wont give enough information to root cause the problem. An example of that script is below. You can find the documentation for these state machines here (session)http://src.opensolaris.org/source/xref/nwsc/src/sun_nws/iscsi/src/iscsi_sess.c#674 and (connection)http://src.opensolaris.org/source/xref/nwsc/src/sun_nws/iscsi/src/iscsi_conn.c#319 . In addition I posted some light information about this years ago in a blog post here http://blogs.sun.com/dweibel/entry/iscsi_device_reporting_lots_of #!/usr/sbin/dtrace -s sdt:iscsi:iscsi_sess_state_machine:event { printf("%p %s %s", arg0, (string)arg1, (string)arg2); } sdt:iscsi:iscsi_conn_state_machine:event { printf("%p %s %s", arg0, (string)arg1, (string)arg2); } In addition you should report the iscsi login parameter information so support (or we) know how to read the flow of the trace properly. This can be done with <b>iscsiadm list target -v</b> This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
