On 01/19/2011 01:13 PM, Joe Hoot wrote:
Ok. A couple of new questions regarding this:
Here are my currently settings:
#node.session.timeo.replacement_timeout = 120
node.session.timeo.replacement_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 15
node.session.err_timeo.lu_reset_timeout = 20
# To control how many commands the session will queue set
# node.session.cmds_max to an integer between 2 and 2048 that is also
# a power of 2. The default is 128.
node.session.cmds_max = 128
# To control the device's queue depth set node.session.queue_depth
# to a value between 1 and 1024. The default is 32.
node.session.queue_depth = 32
QUESTIONS:
==========
1) *noop_out_timeout* - I found that if I raise my noop_out_timeout to 15
secs, I'm not seeing nearly as many (actually I haven't seen any timeouts
for the last hour that I've been testing). Should I previously had this set
to 10. In the network world, it just seems that 15 seconds is a really
really long time to actually wait for a noop ping response (I'm relating
this to ICMP pings, but still...). Is it common for users to set the
noop_out_timeout this high?
Hey,
I am sick, so I will try to answer this one now and answer the others
tomorrow (going to go back to sleep now).
I think 5 secs is actually a longish timeout. Is this problem easy to
replicate and can you do some testing? Could you turn on all debugging?
If this is a RHEL 5 based kernel then it would be
echo 1 > /sys/module/libiscsi2/paramters/debug_libiscsi
echo 1 > /sys/module/libiscsi_tcp/paramters/debug_libiscsi_tcp
echo 1 > /sys/module/iscsi_tcp/paramters/iscsi_tcp
This ends up printing around 5 lines for every IO, so there will be lots
of info in /var/log/messages. So if you have to run a test for hours
then this might be a problem. If you can recreate the problem quickly
this would log info would be helpful so we can see if we are getting
responses to other IO or of maybe there is a complete stall for a while.
If you can also get tcpdump at the same time it would be helpful so we
can see if the network layer is sending data. Something like
tcpdump -i $ETHX -w iscsi.out
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
