Hi all, these two patches update the TMF handling to make it more efficient and less error prone.
The first patch is just a minor tweak to allow new TMF tasks as soon as we've received a response for the pending one. Reasoning here is that eg LUN Reset might take quite a while to abort all outstanding tasks, during which time we cannot send any other LUN Reset even to another LUN. So obviously, allowing another LUN Reset here is the right thing to do. And even if we would be sending a LUN Reset to this LUN we wouldn't do any harm as the SCSI command abort is protected by a lock, so nothing will happen here for consecutive LUN Resets. And of course we're observing the error recovery hierarchy, so an ABORT TASK will be rejected if LUN Reset is in progress. The second patch is the more important one, as it fixes an error during LUN Reset handling in the initiator. When sending a LUN Reset during an ongoing R2T transfer, we're suspending Tx and aborting all _SCSI_ tasks. However, once we're done there we're resuming Tx and the R2T transfer will happily continue. So we should rather be checking for ongoing TMF tasks in iscsi_task_xmit and terminate the I/O of the task affects us. Note we're not actually interested in the outcome of the TMF task as the I/O will be stopped anyway even if the TMF task fails. 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 -~----------~----~----~----~------~----~------~--~---
