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:
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?
From what I've gathered, the MSA target in this case will return a
TMF response even when not all data-outs have been received, and
after a certain time will drop the connection to trigger ERL0.
Basically, all I'm trying to do is to run this test-case:
(bonnie/dt on all devices)
for d in /sys/bus/sd*; do
sg_reset -d /dev/${file##*/}
done
The result of this test run is that in ca 90% sg_reset will
run through, but the other 10% cause a full ERL0.
And I'm trying to determine the reason for this pecularity.
Weird, though, that apparently I'm hitting quite a bunch
of issues here ...
Or...
Are you talking about if we have task 0 and task 1 in progress, then
send a lu reset that should affect those two tasks, but then we get a
task2 in the cmdqueue list, and then we get a tmf response, so we end up
cleaning up task0, task1 and task2? If so, how does the target barf here
(is it a connection drop or some error because the task does not get sent)?
Hmm. Checking ...
No, I won't be sending any other SCSI command PDU to the affected LUN; that's
being blocked by the check_tmf_restrictions() function.
If this is your problem, then your patch would work under normal
conditions, but if you have sndtmo=1 then you could still hit this
problem a little more easily than normal. If the sendpage code returned
EAGAIN (which gets converted to ENOBUFS in your patch) due to the sndtmo
then we will return from
iscsi_data_xmit without completely sending the task or any task behind
it (if there was also a task3 queued).
We could also hit the problem, where if task0 was affected by a TMF then
iscsi_data_xmit returns EACCESS. Then task2 is not going to get sent,
because it is stuck behind task0 on the cmdlist. I think in the patches
[PATCH 1/5] libiscsi: Allow multiple LUN Reset TMF
[PATCH 2/5] Check for TMF state before sending PDU
you need to also modify conn-tmf_state and clear the conn-tmf header
before suspending the xmit thread.
I was thinking about this the other day and I think we can jsut add a
check in fail_scsi_task to check for tasks with a cmdsn less than the lu
reset cmd's cmdsn, right? Maybe we want to fail the affected tasks with
DID_ERROR, but then for the non-affected tasks we could fail with
DID_IMM_RETRY. So then if this was a reset from something like sg_reset
those tasks that were not affected would get another full timeout period
to run in case the lu reset took a long 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.
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
-~--~~~~--~~--~--~---
