Mike Christie wrote:
> On 08/07/2009 05:27 AM, Hannes Reinecke wrote:
>> LU Reset TMF can take quite some time to abort all pending
>> commands. Any other TMF submitted at that time will autmatically
>> fail. However, there is no reason to not allow another
>> TMF once we received the response as the only shared resource
>> here is the complete callback.
> Could you answer my question on how you are testing this?
See my other mail. I'm injecting LU Reset operations via sg_reset.
And occasionally the LU Reset stalls for quite some time, so
that I would be able to send a LU Reset to other LUNs; only, I
can't as I can send only one LU Reset via a connection/host.

> scsi-ml eh only allows one eh operation, and injecting tmfs tries to
> only allow one (there is a race though).
Yes, but this disregards user-space initiated resets.

> How useful is this too? Did I ask this before? Is the cleanup taking
> that long in some cases? If so, what are the cases?
Oh, various. Occasionally the target just stalls for some time, in
others it takes us quite some time to abort all outstanding tasks
(mostly due to logging; I'm logging every SCSI cmd abort via serial console)

But on further checking, we'll have to keep the tmf hdr around currently
so as to check which device / LUN is affected. So we cannot send
concurrent TMFs anyway as we would overwrite the header then.

Alright, you're correct. Doesn't make sense.
Ignore it.


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

Reply via email to