On Wed, 2014-03-12 10:40 AM, Nicholas A. Bellinger wrote:
> On Tue, 2014-03-11 at 04:27 +0000, Alex Leung wrote:
> > On Mon, March 10, 2014 6:01 PM, Nicholas A. Bellinger wrote:
> > > On Fri, 2014-03-07 at 02:04 +0000, Alex Leung wrote:
<SNIP>
> >
> > How can the fabric driver distinguish between this case (Abort Task)
> > that would never send TASK_ABORTED and, say, LUN RESET, that would send
> > TASK_ABORTED (provided that the TMR came from a different IT Nexus)?
> >
>
> Not sure I completely understand the case above where ABTS was received,
> but no response will be sent for the FCP_CMND itself, but I'd assume
> using the reference tag included in the original ABTS to set a fabric
> dependent descriptor bit to distinguish this special case.
>
This can be done, but it would be nice if the indication of whether or not
to send a response was made explicit.
> Otherwise, a se_cmd specific bit to signal ABORT_TASK vs. LUN_RESET
> might be helpful..
>
Or maybe a "suppress response" bit? So TASK_ABORTED with
suppress_resp=0 would tell fabric driver to send TASK_ABORTED for the
FCP_CMND and TASK_ABORTED with suppress_resp=1 would indicate
to fabric driver to cleanup internally without sending a response. The
fabric driver would then neither know nor care about what caused the
abort.
> > > > core_tmr_handle_tas_abort() has the following 'if' statement before
> > > > calling transport_send_task_abort():
> > > >
> > > > if ((tmr_nacl &&
> > > > (tmr_nacl == cmd->se_sess->se_node_acl)) || tas)
> > > > transport_send_task_abort(cmd);
> > > >
> > > > It makes sense that if TAS=1, the .queue_status downcall would be
> > > > made with scsi_status=SAM_STAT_TASK_ABORTED. However, I
> > > > don't understand the
> > > > "(tmr_nacl && tmr_nacl == cmd->se_sess->se_node_acl)" part of
> > > > this statement.
> > >
> > > IIRC, this is because TAS only effects nexuses other than the nexus
> > > that received the LUN_RESET.
> > >
> > > > When I configure TAS=0 and send a LUN Reset, the tmr_nacl matches
> > > > the se_node_acl so the call to transport_send_task_abort() is made
> > > > regardless of "tas". I would think that if TAS=0, the
> > > > transport_send_task_abort() call would be skipped. What am I
> > > > missing?
> > > >
> > >
> > > From SPC-4's description of TAS:
> > >
> > > "A task aborted status (TAS) bit set to zero specifies that aborted
> > > commands shall be terminated by the device server without any
> > > response to the application client. A TAS bit set to one specifies
> > > that commands aborted by the actions of an I_T nexus other than the
> > > I_T nexus on which the command was received shall be completed
> > > with TASK ABORTED status (see SAM-4)."
> > >
Note: if TAS is zero, "commands shall be terminated by the device service
without any response"
> > > My understanding wrt to TAS has been that it only effects nexuses
> > > other than the one that received the LUN_RESET.
> >
> > I agree, that's why I would have expected to only send TASK_ABORTED if
> > TAS=1 and the TMR came from a different IT Nexus. Something like this:
> >
> > if ((tmr_nacl &&
> > (tmr_nacl != cmd->se_sess->se_node_acl)) && tas)
> > transport_send_task_abort(cmd);
> >
>
> My understanding is that TASK_ABORTED is still expected to be sent on
> the nexus the TMR LUN_RESET was received upon, regardless of the TAS bit
> setting. This is what the code above reflects.
That's not how I understand it. I think the first sentence from your SPC-4
snippet says it all, as I noted above. Also, according to Table 38 -
SCSI device conditions that abort commands in a SCSI initiator
device (SAM-4):
""Yes" indicates that each command that is aborted on an I_T nexus other
than the one that caused the SCSI device condition is completed with
TASK ABORTED status, if the TAS bit is set to one in the Control mode page
(see SPC-4). "No" indicates that no status is returned for aborted
commands."
I could not find anywhere where an exception is made for the nexus
the LUN Reset was received upon.
Thanks,
Alex
��.n��������+%������w��{.n����j� ����{ay� ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��
