ACA handling for "tempor

[Jim McGrath]

        Reply to:   RE>ACA handling for "temporary initiators"


On the "rippling" initiator problem presented by Gerry, I have to agree with
Jeff WIlliams - the B device was assuming the role of initiator for this
operation to device C (and probably other devices), so it must also deal with
error recovery operations.  Since device C usually can handle all of its own
internal recovery, I assume this means keeping coordinated data between
device C and other devices.  That is, suppose C has the user data, but device
D has the (correctly updated) parity.  Then the strip is now inconsistent.

Note that if we ripple up the error recovery responsibility, then the
mechanism must be extendable, since the RAID model allows 4 levels of depth
in a RAID subsystem.  i.e. device C could have been in the process of
exeecuting commands as a controller device to other devices lower in the tree
of devices.

Note that using the Third Party Reservation mechanism operates ok if we
really want to transfer responsibility to A.  B would execute it, reserving C
for A and ending the allegiance between B and C.  Some "status" can be
delivered from B to A, alerting it that it should now handle C.  The only
strange thing is that B ultimately has to release C, so A has to tell it to
do so when it is done.  This would work if the "status" B returned to A
created an allegiance between B and A, and when that allegiance was closed by
A it was used as a signal for B to release C.  Note that this particular
solution does not work if a device D is at a level lower that C and created
the sequence.

To my mind what this really points out is that if Seagate is serious about
these commands, then they have to be submitted to the committee as work
items.  There are probably a LOT of problems like this in the concept
presented, and I do not support the committee spending a lot of time on it if
it is not being proposed as an action item for, say, SCSI-3.

Jim