On 03/26/2015 07:43 PM, Kashyap Desai wrote: >> -----Original Message----- >> From: Hannes Reinecke [mailto:[email protected]] >> Sent: Thursday, March 26, 2015 9:28 PM >> To: Kashyap Desai; [email protected] >> Subject: Re: Scsi Error handling query >> >> On 03/26/2015 02:38 PM, Kashyap Desai wrote: >>> Hi Hannes, >>> >>> I was going through one of the slide posted at below link. >>> >>> http://events.linuxfoundation.org/sites/events/files/slides/SCSI-EH.pd >>> f >>> >>> Slide #59 has below data. I was trying to correlate with latest >>> upstream code, but do not understand few things. Does Linux handle >>> blocking I/O to the device and target before it actually start legacy EH >> recovery ? >> >> Yes. This is handled by 'scsi_eh_scmd_add()', which adds the command to >> the >> internal 'eh_entry' list and starts recovery once all remaining >> outstanding >> commands are completed. > > Thanks Hannes..! Scsi_eh_scmd_add() move shost state to recovery, so it > means blocking further IO to the Host and not really a limited to > Device/Target for which command was timed out. Right ? > I understood that, new improvement of scsi error handling will allow IOs to > the other Devices attached to the host except the IO belongs to specific > target. > > Also, one more thing to clarify... In presentation, term "task set aborts" > was used. Does this mean task set abort is handled as traversing complete > list of timed out command and sending individual TASK ABORT ? > No. The idea was to send 'task set aborts' as a single TMF. However, I'm not sure if I'll be going ahead with that one; once we've issued a 'transport reset the commands will be cone anyway.
Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
