On Wed, 2016-01-27 at 12:06 +0100, Thomas Glanzmann wrote: > Hello Nab, > > * Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> [2016-01-27 09:12]: > > initiator login basis. The ESX iSCSI initiator honors this limit for > > limiting the outstanding I/O per sesssion, separate from some well > > known ESX scheduling fairness issues with multi-LUN sessions. > > could you please elaborate on the 'well known ESX scheduling fairness > issues with multi-LUN sessions'? > ESX software iSCSI initiator has a long-standing fairness issue where LUNs in a multi-LUN session can be starved, when other LUNs in the same session are doing heavy sustained I/O. That is, the ESX hardcoded SCSI timeout for a given I/O can spend a non trival amount of time waiting to be dispatched in it's internal queue, before actually pushed out PDU out on the wire. It's still unclear (to me at least) at what number of LUNs per session this becomes a problem for ESX, but I usually recommend users keep it in the half dozen range (or less) per individual TargetName +TargetPortalGroupTag endpoint. The ESX initiator's default_cmdsn_depth also seems to have an effect too, especially if the value is smaller than the total number of LUNs for the session and it really begins to contend internally for new CmdSN window slots. -- 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
