On Mon, 26 Jan 2015 12:49:57 +0900 MINOURA Makoto / 箕浦 真 <minoura@xxxxxxxxxxxxx> wrote: > > |> In <kk5iofyfjem.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> > |> "MINOURA Makoto / 箕浦 真" <minoura@xxxxxxxxxxxxx> wrote: > >> tgtd does not send ExpCmdSn and MaxCmdSn with OP_R2T (Ready >> To Transfer) operations. Is this behaviour correct? > > I found the following in 3.5.1.6. Ready To Transfer (R2T), > RFC 3720. > > ---- > R2T also carries information required for proper operation > of the iSCSI protocol, such as: > > - R2TSN (to enable an initiator to detect a missing R2T) > - StatSN > - ExpCmdSN > - MaxCmdSN > ---- > > Thus I think it is a bug in tgtd not in the Linux initiator. > > >> At least Linux (RHEL6.2) initiators take 0 MaxCmdSn value >> and get confused. > > Linux initiator ensures on updating CmdSn's that the new > value is greater (in terms of RFC1982) than the previous. > When the previous value is less than 0x80000000 the new > value 0 is less than the previous and is simply ignored. > Once the session's MaxCmdSn counts up to 0x80000000, it is > updated to 0 (greater than the previous) when tgtd sends an > R2T. The next CmdSn should be around 0x7fffff80, which is > greater than the MaxCmdSn value (0), and flow control works > to prevent sending the next command. > > If there's no R2T in the small window where MaxCmdSn >= 0x80000000 > and CmdSn < 0x80000000 probably nothing happens except > that MaxCmdSn flow control would not work (no limit) until > the actual MaxCmdSn wraps to 0. Applied, thanks a lot for the detailed investigation! -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
