Hannes Reinecke wrote:
> Mike Christie wrote:
>> On 08/07/2009 05:27 AM, Hannes Reinecke wrote:
>>> We should be flushing the workqueue before setting the suspend
>>> bit. If we don't a LU Reset might kill commands which are already
>>> in the queue and waiting to be send, causing the target to barf.
>> What do you mean here? What do you mean by barf? What commands in what
>> queue?
>>
> In the 'requeue' queue. There might be Data-out requests still waiting
> to be sent, but we can't as the xmit thread would be short-circuited
> as we've set the SUSPEND bit.
>
>> Are you talking about the problem where we get a tmf response, and do
>> not send data-outs? If so this will not always help. The data-out could
>> be on the wire and the target could still hit the problem. The problem
>> is not ours. The target should not send a tmf response that indicates it
>> was successful if there is a r2t that is in progress of being fullfilled.
>>
> That is a matter of interpretation. The targets seem to implement the wording
> of RFC5048, section 4.1.2:
Why do you do this :) I asked about this when you brought up this
problem the day before sending your patches? Why do you always ignore
the first mails so we have to talk about it again after you have done a
patch :)
>
> 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.
Can it also send a check condition for the task? I think Erez had asked
about what to do if you do not get a data-out in the non tmf case, and
Julian had said you can send a check condition, but we had that
discussion for that other bug on the list about if you can send a scsi
cmd response pdu when a r2t is active.
My problem is this for the initiator:
10.6.2.
Receives the task set management response, thus concluding all the tasks
in the affected task set.
So I am taking this to mean that when this happens and we get a response
that indicates the tmf executed successfully then the task is done on
both sides.
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.
>>
> I actually thought about the same lines, and even added some CmdSn printks.
> However, the CmdSn of running task is not getting updated, so currently
> these are quite pointless. But I can see what I'm getting.
>
I think we are talking about different issues. You can check if the
cmdsn has been set or not and make a decision based on that as well as
the lun. The problem I was thinking about is if we the tmf gets sent
before some task, then we will not send that task. However,
scsi_fail_tasks will return all task with a matching lun with DID_ERROR.
So that task will get the allowed/retry count incremented on it even
though it did not get sent. So you would do
scsi_fail_task()
if (task->lun == lun) {
if (cmdns is set and is less than conn->tmf's lun)
fail with DID_ERROR
else
fail with DID_IMM_RETRY
}
We can save this for later since it should be rare as the sg reset
injection tries to stop queueing.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
