System recovery on 3rd p

Jim McGrath jmcgrath at
Mon Aug 22 19:54:20 PDT 1994

        Reply to:   RE>System recovery on 3rd party commands

    (C) Drive A can issue a 3rd party RESERVE command to drive B, reserving
it to
    the RAID controller. This would lock out other devices until the RAID
    controller completes its recovery action. The RAID controller would still
    to learn the failing drive address from the failing XDWRITE command bytes
    resulting sense bytes, just like in case (B). The problem with this
    occurs when the RAID controller is done with recovery and tries to
release the
    3rd party reservation. The existing SCSI rules prevent the RAID
controller from
    releasing its own reservation, only the device that sent the 3rd party
    command (drive A) can release the reservation.

I would suggest that the reservation of drive B by drive A for the host be
as part of the command execution at drive A for the host.  Drive A would then
report status to the host, indicating that a reservation was in place (since
the host had to give drive A the original ID for drive B, a simple ASC will
ACA is valid at this time between the host and drive A, with drive B being
reserved by drive A for the host.  The host then proceeds to perform recovery
operations on drive B.  When it is done, it releases the ACA for drive A,
indicating implicitly the drive A RELEASE drive B.  At this point everything
is back to normal.


More information about the T10 mailing list