Re: [storage-discuss] iSCSI Boot Target

[Peter Cudhea]

Thanks, Nigel for this excellent analysis. The remaining issue you describe sounds like the "phase collapse" issue being tracked in RFE CR 6766563.  The description from that CR: Phase collapse is an iscsi mechanism that allows the SCSI status to be sent along with the last data PDU of the command provided the command was successful.  This eliminates the need to send a separate SCSI status PDU and for small reads this can be a signicant reduction in overhead.  Supporting this will require changes in both idm and iscsit. Over the last week or so, there have been a series of issues recently with "small and simple" iSCSI initiators that want to work with minimal negotiation and then do the data path in a straightforward request-reply model.   This is the third such initiator I have heard of this week. The  characteristics of COMSTAR iSCSI that the small and simple initiators have had trouble with include: COMSTAR iSCSI will not negotiate InitialR2T=No., but only the iSCSI default setting of InitialR2T=yes. The small and simple initiators are not set up to deal with R2T messages, and want to deal with Immediate data only.   By negotiating InitialR2T=no they hoped to make it impossible to receive R2Ts.  (It is not really needed, if they rely on Immediate Data only.)  In two cases we have analyzed, the initiator did not really depend on being able to send unsolicited data PDUs, and could be modified to ask for InitialR2T=yes.  In both cases,  the simple act of not agreeing with everything the initiator asked for was enough to cause a problem.  Neither initiator had been tested against a target that did not immediately comply; there were bugs lurking in the non-tested portion. The lack of phase collapse.  With phase collapse, the response to a simple READ command that fits within the initiator's value for MaxRecvDataSegmentLength will come back in a single PDU that contains both data and status portions.   Without that feature, the initiator must be able to receive 2 response PDUs in response to a single request PDU.  Once again, there was a bug lurking in the non-tested portion. The NOP messages generated by COMSTAR iSCSI have also been rumored to be an issue in one case, but so far not a major issue.   A truly simple initiator might not be set up to deal with ANY messages outside of the request-reply model, including these NOP messages. We are working through the issues bit by bit as needed, including working with the initiators to modify their code where possible.  Thanks to the community for bringing these areas to our attention. Peter Nigel Smith wrote: Following Vazer's initial post to the storage forum, there followed a number of email directly between Vazer and Peter Dunlap & myself, which I want to summarise here... Vazer did a great job collecting Ethernet packet capture trace files, enabling a comparison of the behaviour of the Comstar iscsi target, with the Microsoft iscsi target and the NetApp iscsi target. Vazer identified a couple of scenario where the Comstar target failed. Vazer emailed the capture files to Peter Dunlap & myself,and it was interesting to analyse these files and see where they went wrong. :--------: First let's look at Vazer's "Not Working Scenario 2": "The Physical Server is booted with the iSCSI Offload NIC enabled in BIOS." Vazer was trying to boot Windows 2003 server from the LUN, and it stalled saying "NTDETECT failed". When I looked at the trace, I could see the iscsi boot started fine, with many 'Read(10)'s with transfer lengths of 1, 2, or 8 block. Then a point was reached where the initiator did a read with a requested transfer length of 20 blocks. At which point the Comstar target responded with scsi status code 0x28 meaning 'Task Set Full' http://en.wikipedia.org/wiki/SCSI_Status_Code Vazer tried the iscsi boot afew times and the trace files always stopped in exactly the same place. Peter Dunlap identified the problem as happening because the NIC was negotiating a very small value for MaxBurstLength (0x2000) The stall occurred when attempting a transfer of size 0x2800 (20 block, each of 512 bytes = 10240'd = 0x2800). This is the issue tracked by bug 6867945, for which a fix was recently putback. :--------: Now let's look at Vazer's "Not Working Scenario 1": "Server booted with Windows 2008 with HyperV, but the MS iSCSI Initiator connects to the target using the broadcom multifunction NIC with its offload iSCSI capabilities. There is no LUN recognized by the Initiator. With a NetApp iScsi target or Microsoft target this works fine." In the trace file I could see the initiator sending 'Report LUNs' three times, with allocation length of 16. Each time it gets the same response from the comstar target, 'Status Good' and LUN List length 8, LUN 0. (Which is valid, but the initiator does not seem to like it.) This is then followed by the initiator sending 'Inquiry LUN' three times, all with EVPD zero, page zero, and allocation length 36. Each time it gets the same response from the comstar target, That response is 'Status Good'.(Which again should be ok.) And at this stage it stalls. The equivalent traces for the Microsoft and NetApp targets give the same response to 'Report LUNS', but then the initiator continues on Ok and the only difference I could spot was they set the status flag 'S' to say that status accompanies the Data-In pdu. Peter Dunlap thought the cause of the problem may be the issues tracked by bug 6818484, which was fixed in snv_113. However Vazer retried the scenario with snv_117, and still had the problem. AFAIK the issue is unresolved. Best Regards Nigel Smith

_______________________________________________
storage-discuss mailing list
storage-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss