Task Management

Larry Chen larryc at maxstrat.com
Thu May 14 17:19:19 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Larry Chen <larryc at maxstrat.com>
*

Hi Bob,

Thanks for your comments.
My responses to your comments are below.
-Larry

On Wed, 13 May 1998 16:58:39 -0700 (PDT)  Bob Snively wrote:
>Larry,
>
>Doesn't the "Clear Task Set" task management function clean out everything that
>has already been sent for all initiators?

Yes, for that one lun device.

IMHO, sometimes all ports and luns on the loop must be reset in
some way by the SIM when a command timeout occurs. When a command
timeout is detected by the SIM, any hardware and/or firmware on the
FC-AL loop may be the cause for the command timeout. 

>The only things exposed are
>commands enqueued at the host adapters but not yet delivered to the targets.
>The first of those for each initiator will get a Unit Attention, 
>indicating it should also do some clean up, probably Abort Task Set, 
>which will clean everything else.  Note that this approach subverts the
>timeout requirement by blasting everything once notice has been posted.
>A Clear Task Set for tasks if no other tasks are sent out will be detected
>only by a command timeout, but that isn't a very busy device anyway, unless
>you are executing long commands without progress reporting and the immediate
>bit.

I like your idea :)
This would allow the SIM to use the 1 BIG hammer approach
(and drop the smaller hammer based on Abort Task Set).

>
>If I were running a high availability cluster, I would not want some 
>device to actually go out and do any of these things to the whole cluster.

I do NOT think I am advocating this approach.
Given that the whole cluster is on shared FC-AL loops, I think
there are some cases where the SIM layer may choose to reset all
the ports and luns in some way (i.e., Target Reset to all logged in
ports).

I view the Persistent Reserve and Release stuff as higher
level issues (access control, fail over) than the SIM command timeout
error recovery issue.
 
>Rather, I would want to be able to selectively disable and clean up the
>work being performed by a misbehaving host, using the Preempt and Clear
>service action of the PERSISTENT RESERVE OUT command.  
>
>The nice thing about the Preempt and Clear service action is that the host
>cannot rejoin the party until it has gone through a very special
>series of commands to reregister itself.  As a result, any host
>obeying the software conventions would rejoin in a very disciplined manner.
>All bets are off for actively malicious hosts.  In addition, any subsequent
>commands that were queued but not delivered would be terminated with
>RESERVATION CONFLICT status, a perfect indicator of failure.
>Note that this does not require command timeouts for recovery.



>
>
>> Date: Tue, 12 May 98 16:13:33 PDT
>> Subject: Re: Task Management 
>> To: T10 at Symbios.COM, Bob Snively <Bob.Snively at Eng>
>> MIME-Version: 1.0
>> 
>>      
>> On Tue, 12 May 1998 09:24:58 -0700 (PDT)  Bob Snively wrote:
>> >* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>> >* Bob Snively <Bob.Snively at Eng.Sun.COM>
>> >*
>> >
>> >Folks,
>> >
>> >A properly implemented software convention using the persistent reserve
>> >function appears to me to be precisely what Larry is looking for.
>> >
>> >Bob
>> Hi Bob,
>> 
>> I am trying to implement a simple and highly reliable command timeout
>> error recovery scheme at the SIM layer. 
>> 
>> My philosophy is to use the BIGGEST hammer allowable for a
>> multi-initiator FC-AL environment which will prevent ping-pong
>> actions between the initiators.
>> 
>> In the good old days of parallel SCSI, SCSI Bus Reset could be sent.
>> If my memory serves me correctly, SCSI Bus Resets were seen by all
>> devices (including other initiators). The important point being that
>> ULP timeouts were NOT relied upon to retry the command(s) that were
>> aborted due to SCSI Bus Reset.
>> 
>> For FC-AL, SCSI Bus Reset is NOT available and can NOT be properly
>> emulated, especially for multi-initiator environments.
>> IMHO, anything less than SCSI Bus Reset is unreliable. Therefore,
>> I envision at least two hammers will be needed now.
>> 
>> 1) one based on Abort Task Set or LIP without issuing ADISC/PDISC
>> Note - with Lun spaces growing to 8 bytes, I think the SIM will
>> be hard pressed to send Abort Task Set to all luns (including
>> multi-lun devices).
>> 2) one based on Target Reset
>> 
>> -Larry
>> 
>> >
>> >> * From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>> >> * ROWEBER at acm.org
>> >> *
>> >> Larry,
>> >> 
>> >> > I would like to issue a single Task Management Request (TMR) to Lun 0, 
>> >> > which will abort all commands under the target device belonging to the
>> >> > requesting initiator.  (i.e., Abort Task Set is issued to all valid lun
>> >> > devices under the target device).
>> >> >
>> >> > Logical Unit Reset is a little too harsh for multi-initiator 
>environments.
>> >> 
>> >> Sorry, no such task management function exists currently.  One could
>> >> propose addition of the function in any of several ways that would
>> >> result in changes to one or more of SAM-2, SPC-2, SPI-3, and FCP-2.
>> >> 
>> >> Ralph...
>> >> *
>> >> * For T10 Reflector information, send a message with
>> >> * 'info t10' (no quotes) in the message body to majordomo at symbios.com
>> >
>> >*
>> >* For T10 Reflector information, send a message with
>> >* 'info t10' (no quotes) in the message body to majordomo at symbios.com
>> 
>> -------------------------------------------------------
>> Larry Chen             Tel: 408.383.1600 (x116)
>> MAXSTRAT Corporation   Fax: 408.383.1616
>> 801 Buckeye Court      E-mail: larryc at maxstrat.com
>> Milpitas, CA 95035     URL: http://www.maxstrat.com/
>> -------------------------------------------------------
>> 
>> 
>> 
>

-------------------------------------------------------
Larry Chen             Tel: 408.383.1600 (x116)
MAXSTRAT Corporation   Fax: 408.383.1616
801 Buckeye Court      E-mail: larryc at maxstrat.com
Milpitas, CA 95035     URL: http://www.maxstrat.com/
-------------------------------------------------------


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list