Mike Christie wrote:
> Mike Christie wrote:
>> Hannes Reinecke wrote:
>>> Mike Christie wrote:
>>>> Hannes Reinecke wrote:
>>> [ .. ]
>>>>> Fsck. You are correct.
>>>> But you still might be hitting a problem where the target does not like 
>>>> data-outs when it closed the window. Maybe they interpreted the RFC 
>>>> differently. You should ask the HP target guys for more info.
>>>> Also your patch might be working because I think it ends up throttling 
>>>> the connection, so IO does not timeout because pipes are backed up (the 
>>>> slow down from the throttling is one of the problems we hit with the 
>>>> patch I did before which was pretty much the same as you posted).
>>> I actually had quite good results with it, so it can't be too bad :-)
>>> IE the test HPs running continued for over a day, whereas previously
>>> it'd stall after some hours.
>> Yeah, I saw the bz update too.
>> I tested your patch out here localy just to double check that is works 
>> like what we had before. With a istor target write throughput goes from 
>> 50 MB/s to 15 MB/s. It eventually dies (ping timeout) because the window 
>> is closed and it does not open until we finish sending the data-outs for 
>> the currently running commands. So READs are just fine. We hit the 
>> window closed check but we continue to make progress on the READs 
>> because data-ins are processed like normal and the window opens back up 
>> as commands are completed.
>> So someone is doing something screwy. I am testing a EQL box locally now 
>> and will try some others just to double check.
> Hannes, could you test without your cmdsn patch, but then set things up 
> so we do not have to send data-out pdus?
> You want immediate data = Yes.
> node.session.iscsi.ImmediateData = Yes
> node.session.iscsi.FirstBurstLength = 131072
> Then either send IOs that are smaller than 131072 or set the 
> /sys/block/sdc/queue/max_hw_sectors to 128
> For the target you would want
> ImmediateData = Yes
> FirstBurstLength = 131072
> MaxRecvDataSegmentLength = 131072
> I guess you would want to lower the initiator values to match what the 
> target is going to ask for if you cannot modify the target.
> I am seeing a problem here when having to send data-outs even when the 
> window is open, throughput dies from 111 to .61 MB/s.

It might not be the data-out in response to a R2T. I ran with this:

ImmediateData = No
InitialR2T = Yes

when you login make sure that  iscsiadm -m session -P 3 has

                ImmediateData: No
                InitialR2T: Yes

And now it all works. Before I was barfing with IET and EQL. I could not 
replicate it on a iStor because it always uses those values.

It might be due to a data-out when InitialR2T=yes or if we have sent 
immediate data with the scsi cmnd and then send a data-out in response 
to a r2t. will try that next.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to