Hi Martin, Apologies for the delayed response. My comments are below.. On Thu, 2013-02-07 at 17:12 +0100, Martin Svec wrote: > Hello, > > when our ESXi hosts (re)connect to an iSCSI target, I sometimes see > the following errors in dmesg: > > [248476.396730] sock_ops->getname() failed. > [248476.396734] tx_data returned less than expected > [248476.396735] iSCSI Login negotiation failed. > [248476.396782] tx_data returned -32, expecting 112. > [248476.396785] iSCSI Login negotiation failed. > [248476.396802] sock_ops->getname() failed. > [248476.396805] tx_data returned less than expected > [248476.396806] iSCSI Login negotiation failed. > [248476.396811] sock_ops->getname() failed. > [248476.396813] tx_data returned less than expected > [248476.396814] iSCSI Login negotiation failed. > > [249424.088714] tx_data returned -32, expecting 112. > [249424.088717] iSCSI Login negotiation failed. > [249424.339221] rx_data returned 0, expecting 48. > [249424.339224] iSCSI Login negotiation failed. > > It usually happens when I disable and remove the target setup from > /sys/kernel/config and then configure+enable it again few seconds > later. That is, when vSphere hosts are intensively trying to establish > new sessions. Is it something I should worry about? ESXi quickly > repeats login attempts until it succeeds so there is no long downtime, > but the errors look strange (negative tx_data, sock_ops->getname() > failure?). > So I've encountered this issue with ESX before, which ends up involving a couple of different points.. First, these messages are caused by the ESX side aborting iSCSI login attempts when LoginTimeout (5 seconds by default on ESX v5.x) has been reached. Increasing this default value on the ESX side (the limit is 60 seconds) will help avoid this to an extent, based upon the total number of sessions that are active. Second, one work-around on the target side is to avoid the allocation of RX/TX thread-sets at login time. This can be done by increasing the drivers/target/iscsi/iscsi_target_tq.h:TARGET_THREAD_SET_COUNT value from the default of 4 to roughly match the totally number of sessions that you expect from the ESX side. This will cause more RX/TX thread-sets to be allocated at modprobe iscsi_target_mod time, instead of at login time. Note this work-around primarily helps when CHAP authentication is disabled, when only a single Login Request -> Login Response are sent across the wire to complete a given login attempt. Lastly, adding support for login socket multi-plexing is the proper long-term fix to address the extra latency involved with CHAP authentication when there is a large number of login attempts in flight, requiring having to exchange multiple Login Request / Response PDUs per connection in order to complete each login. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
