On 07/23/2009 04:32 PM, Mike Christie wrote:
> 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

Turns out it was bad hardware and old firmware. I updated both and it 
works now.

I think it is still good to try different settings to narrow down which 
type of pdu is causing problems. By setting the q's max_sectors and 
using immediate data you can prevent data-outs from having to be used.

--~--~---------~--~----~------------~-------~--~----~
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 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to