There is a new command in SPC-4 called REMOVE I_T NEXUS that is intended to help that situation. REMOVE I_T NEXUS lets the application client use a good I_T nexus to abort commands that were being processed on a bad I_T nexus, so it can safely re-issue those commands on the good I_T nexus without worrying that the original commands might resume.
In contrast: - the ABORT TASK, ABORT TASK SET, and CLEAR TASK SET must use the same I_T nexus as the commands being aborted, so are not viable if that I_T nexus is bad - LOGICAL UNIT RESET aborts commands from every I_T nexus, so in addition to aborting commands from the bad I_T nexus it also affects commands on the good I_T nexus > -----Original Message----- > From: [email protected] [mailto:linux-scsi- > [email protected]] On Behalf Of Ewan Milne > Sent: Tuesday, 27 November, 2012 2:03 PM > To: [email protected] > Cc: Hannes Reinecke; SCSI Mailing List; Andrew Vasquez; Chad Dupuis; > James Bottomley > Subject: Re: Error handling on FC devices > > On Mon, 2012-11-26 at 17:32 -0500, James Smart wrote: > > Given path switching is somewhat separate from the i/o, would it better > > to send a notification of a path-fail condition as part of the eh, > > rather than hinging it on the individual i/o. Yes, the i/o is still in > > limbo and can't be switched to the new path, but other i/o could without > > incurring the delay. > > Is there a potential issue with a write that is taking a long time on > one path, which could cause path switching for subsequent writes to > another path, before the disposition of the first write is known? > > > -- > 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
