Mike Christie wrote:
> Mike Christie wrote:
>>> The target iSCSI layer:
>>> - MUST wait for responses on currently valid target-transfer tags of the
>>>   affected tasks from the issuing initiator.
>>>
>>> So, a 'wait' clearly indicates some sort of timer on the target side.
>>> However, what should be the response if not all ttt are being received
>>> from the initiator?
>> I think the target should do what it does when this happens and a tmf is 
>> not being sent. Depending on the erl the target can send a recovery r2t, 
>> it can start connection recovery, it can resort to session recovery.
> 
> 
> Hey, I forgot the rfc quote. It was 10.5.1:
> 
> For ABORT TASK SET and CLEAR TASK SET,..... The
>     target on its part MUST wait for responses on all affected target
>     transfer tags before acting on either of these two task management
>     requests.  In case all or part of the response sequence is not
>     received (due to digest errors) for a valid TTT, the target MAY treat
>     it as a case of within-command error recovery class (see Section
>     6.1.4.1 Recovery Within-command) if it is supporting
>     ErrorRecoveryLevel >= 1, or alternatively may drop the connection to
>     complete the requested task set function.
> 
> 
> For the digest errors part, I was not sure if it only meant digest 
> errors. I thought it could mean any old problem. Also I thought the 
> abort task set comment would hit the multi task abort comment in 5048.
> 
>>
>> We should probably take this to the ips list, because it does also say 
>> we MUST continue to respond to each TTT received for the affected tasks. 
>> My reading was that we should just never end up in a situation where we 
>> have TTTs and get a tmf response that indicates the tmf completed ok at 
>> the same time.
>>
> 
> So I am really not 100% sure, so if you do not agree with me here is the 
> mail I wanted to send to the ips list:
> 
> 
> For a single connection session without FastAbort, if the initiator has 
> sent a lun reset and the target has sent a R2T, is it ok for the target 
> to send a task management response with Function Complete, before the 
> initiator has sent the data-out pdus for the R2T? If the target does 
> return the task management function with Function Complete, should the 
> initiator continue to respond to the R2Ts?
> 
Yes, that about sums it up. We could even add:

If so, is it okay to set the 'FINAL' flag in the continued DATA-OUT PDU
so as to end the transfer, even though actual data transfer has not been
completed entirely?

Thanks for this.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                   zSeries & Storage
h...@suse.de                          +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

--~--~---------~--~----~------------~-------~--~----~
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