[EMAIL PROTECTED] wrote on Thu, 17 Apr 2008 14:13 +0300: > On Wed, Apr 16, 2008 at 6:46 PM, Roland Dreier <[EMAIL PROTECTED]> wrote: > > > Agree with the interpretation of the spec, and it's probably a bit > > > clearer that way too. But we have working initiators and targets > > > that do it the "wrong" way. > > > > Yes... I guess the key question is whether there are any initiators that > > do things the "right" way. > > > > > > > 1. Flag day: all initiators and targets change at the same time. > > > Will see data corruption if someone unluckily runs one or the other > > > using old non-fixed code. > > > > Seems unacceptable to me... it doesn't make sense at all to break every > > setup in the world just to be "right" according to the spec. > > This will break only when both initiator and target will use > InitialR2T=No, which means allow unsolicited data. > As far as I know, STGT is not very common (and its version in RHEL5.1 > is considered experimental). Its default is also InitialR2T=Yes. > Voltaire's iSCSI over iSER target also uses default InitialR2T=Yes. > So it seems that nothing will break.
I finally got a chance to look at this just now. I think you mean default is InitialR2T=No above, which means no unsolicited data. That is the default case, and true, the two different meanings of the initiator-supplied VA coincide. But you missed the impact of immediate data. We run with the defaults (I think) that say the first write request packet should be filled with a bit of the coming data stream. From iscsid.conf: # To enable immediate data (i.e., the initiator sends unsolicited data # with the iSCSI command packet), uncomment the following line: # # The default is Yes node.session.iscsi.ImmediateData = Yes Looking at the offset printed out by your patch, it is indeed non-zero for the first RDMA read. Please correct me if I am mistaken about this---you must have tested all four variations of with and without the patches on initiator and target side, but I did not. Hence I am still a bit unhappy about having to deal with the fallout, with no way to detect it. For our local use, I'll keep an older version of stgt in use until we switch to a new kernel, then merge up the target side change. It is a bother, but I can deal with it. For other institutions, this lockstep upgrade requirement will not be obvious until they debug the resulting data corruption. Still, I do understand why it would be nice to conform to the spec, and it is maybe a bit cleaner that way too. Maybe you can help with the bug reports on stgt-devel during the transition, and maintain and publish a patch to let it work with old kernels. -- Pete --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to firstname.lastname@example.org To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---