Always possible - but.... Our f/w works at the FCP level and below,
which means it doesn't know/do SCSI commands - e.g what the cdb within
the FCP CMD frame is; know anything about SCSI device classes and state;
etc. And it shouldn't be required to do so. Anytime this has been there
in the past, it's been problematic.
if we want to do this - we should add it to the midlayer/transport.
-- james s
On 11/28/2012 2:09 AM, Hannes Reinecke wrote:
On 11/27/2012 09:29 PM, Elliott, Robert (Server Storage) wrote:
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
Hmm. Nice in principle, but the problem here is that we cannot
guarantee the nexus is still intact.
So one would need to implement this in the HBA firmware; the firmware
would need to be able to process the TMF, and do the appropriate
things for the FC stack like dropping the rport etc.
Good idea, though.
James, Andrew, Chad?
Any chance of having a firmware supporting REMOVE IT-NEXUS ?
Cheers,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
