Ulrich Windl wrote:
> On 29 Jul 2009 at 13:51, Mike Christie wrote:
> [...]
>> If you check the 
>> LUN while an abort is sent, then you would prevent all IO to the LUN 
>> from being executed instead of just the PDUs related to the specific 
>> command being aborted. So while a abort is sent you do not want data-out 
>> pdus sent for the task and you of course do not want the scsi cmd pdu 
>> (we check that already before we prep the tmf). But you can send new 
>> scsi cmd pdus for new tasks or send data-outs for other tasks.
> [...]
> Hi!
> I'm no SCSI guru, but I don't understand: If you are sending a command abort 
> (I 
> guess this is what we are talking about, or is it a target abort?) to a LUN, 
> I'd 

It is an abort for a specific command like a READ or WRITE to lun1.

> think it's reasonable to wait for the command to abort before sending any 
> other 
> commands to the target/LUN. Are your referring to different LUNs/targets when 
> saying "new or other tasks"?

For lu resets we are talking about preventing IO to the same disk being 
reset, while allowing IO to other disks.

For aborts we are talking about preventing IO for the task being aborted 
but allowing IO for other tasks to the same disks or other ones.

Right now for aborts you are probably right and we probably do not buy 
anything by allowing other IO to run. The current code prevents all 
scsi/data IO from being sent when any TMF is being run (almost all IO - 
there is the bug Hannes found), and I thought that was fine.

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