@ LASER MAGNETIC STORAGE MEMO INTERNATIONAL COMPANY ______________________________________________________________________________ Optical Storage Division 17 November 1987 To: SCSI Standards Committee X3T9.2 From: Paul Boulay (303) 593-4323 Subject: Third Party Reserve Implementation to Support Copy Revision 1 note: The Wichita working group meeting considered this issue and selected the approach presented here. This is a rewrite of Rev. 0 which deletes the third party mode select approach in favor of encapsulating Mode Select parameters in the Copy parameter list. The action item directed that I clarify the permitted modes of storing Mode Select parameters. Revision 2 note: This is the same as Rev. 1 (distributed at the Saratoga Springs plenary), except for adding the EMS bit and moving the Mode Select Area Length field. These changes were suggested by Gary Stevens to allow for future enhancement of the Copy command. Revision 3 note: At the October working group meeting in Orlando the proposal contained in revision 2 was rejected in favor of defining the transference of parameters as a side effect of a 3rd party Reserve. This method puts the burden of appropriately setting up for a Copy on the copy target device that saves parameters on a per SCSI ID basis. To work in all situations this requires precise specification of the action of the target device. In one instance it requires some strange looking actions by the host system while setting up the copy. Acknowledgments are due to Dave Skinner of NCR who drafted some of the new text and who transmitted the results of the Working Group to me. Some implementations of maintaining Mode Select parameters in SCSI target devices can prevent proper operation of device to device Copy commands. If a SCSI target maintains an independent set of mode selections for each possible initiator ID, the Copy Master device does not inherit parameters previously set by the Host. If the target device requires particular mode select parameters for proper operation in a system, means to set them up for Copy operations should be available. The Copy Master must be able to inherit such parameters, be informed of them by direct action of the host or the target device must always supply the correct parameters by default. Storing Mode Select Parameters The SCSI-1 standard provides facilities for the management of Mode Select parameters stored on a one set per device or LUN basis. This traditional method is certainly appropriate for format control parameters tied to the media. It also produces a side effect assumed in the architecture of the COPY command. That side effect is the inheritance of the Mode Selections of the host by a Copy Master. In multi-initiator systems where mode selections may be dynamic, storing parameters on a per SCSI ID basis is better. Embedded SCSI implementations can usually do this easily. Controllers without much RAM, with many LUNs, or with many dynamically alterable parameters may have difficulty. Disconnect/reconnect control, error handling selections and vendor unique operating modes are parameters which can reasonably be dynamic or initiator specific. One advantage of per SCSI ID parameter storage is that each host can separately customize its use of the target device and is not affected by the operations of other hosts via spurious Unit Attentions. (Now, any Unit Attention except media change only will cause a host to send a heavy overhead Mode Select command.) SCSI devices which store parameters by ID do not provide inheritance of mode selections from host to copy master. When devices which store mode selections by SCSI ID are Copy sources or destinations their parameters end up being power up defaults. Approaches to the problems of per SCSI ID parameter storage with device to device Copy are next. Impossible Solutions 1) Disallow saving mode select parameters on a SCSI ID basis. This is a simplistic solution that has two problems. It obsoletes some perfectly good SCSI-1 products and it restricts a mode of operation with general merit because of a special case problem. The CCS document explicitly permitted saving parameters in this manner. 2) Disallow device to device Copy. This makes this special case problem disappear and makes existence less challenging for SCSI controller implementors. However, this approach removes existing functionality from the standard and prohibits a class of solutions to SCSI bus bandwidth limitations. 3) Require that the Copy operation always take place with the power up defaults of devices which save parameters by ID. This is unreasonably restrictive and may make efficiently use of Copy impossible. Possible Solutions 4) Where a target used in a Copy command stores parameters by SCSI ID, the host sends the Copy target devices a new Mode Select option which sets parameters for all possible hosts. In this way the Copy Manager will have the appropriate parameters set up for him. The disadvantage is that it would interfere with other hosts who use the target device. They will get Unit Attention indications but should recover reasonably. This approach could apply only to SCSI-2 source and destination devices. 5) The host sends a 3rd party Mode Select with the parameters the target is to use in upcoming commands from the Copy Manager SCSI device. This has the advantage of letting the host do the Copy set up. In addition it is symmetrical with 3rd Party Reservations. However, this approach applies only to new implementations. 6) Require that the Copy Manager set the appropriate mode. This method allows use of SCSI-1 source and destination devices. The Copy Manager needs a way to determine the appropriate parameters. The host sends Copy Managers a new sort of Mode Select which passes the Mode Select data the copy manager is to send to the target devices. This requires a new Mode Select command option implemented in devices which support device to device Copy. The host would send separate Copy source and Copy destination Mode Select commands. This isn't convenient for copy managers because they would have to store the parameters for future use. (Would separate storage be needed for each host device ID? If not, would the device create a Unit Attention if these were overwritten?) 7) The Copy Manager could send Mode Selects from parameters in the Copy parameter block. This permits operation with existing devices and limits the changes to the copy command. It doesn't assume that the copy manager knows about the other devices, the host system passes all the mode information necessary. However, this approach makes the copy command more complicated. The Orlando Working Group came up with an 8th alternative which is added here. This option is the basis for the suggested text changes given below. The first time this came up it was quickly discarded because the application may not need or want the target device to be reserved for the duration of the copy. With some sleight of hand this difficulty can be avoided. 8) Require that the copy target device transfer the parameters set for use by the host device to those for use by the copy master device. A 3rd Party Reserve received by any device that saves Mode Select and/or other operating parameters by SCSI ID would cause the transfer of parameters. With this approach, the Copy Master need not know about the target devices operating parameters. No new formats are needed in the Copy command or special modes in the Mode Select command. This makes the 3rd Party Reserve a sort of power of attorney function causing the target device to treat the copy master the same way it treats the host. If the host device needs to transfer parameters but does not want to leave the target device reserved, it does a 3rd Party Reserve then a 3rd Party Release. The immediate release nullifies the primary result of the Reserve but the side effect of transferring the parameters to the 3rd party copy master continues. Described below are the proposed additions to the draft standard to carry out this last solution. Add the following to the second paragraph of the Mode Select command text. (Section 8.1.4, Page 8-18 of SCSI-2 Draft Rev.2.) "The target may provide for independent sets of parameters for each attached logical unit or for each combination of logical unit and initiator." "A third party reservation shall cause the target to transfer the set of parameters in force for the initiator of the Reserve command to the parameters for used for commands from the third party device." Add the following new paragraph to the description of Third Party Reservation. (Section 8.1.15.3, Page 8-77 of SCSI-2 Draft Rev. 2.) If the third party bit is one, any subsequent command issued to the logical unit by the third party device shall be executed according to the Mode Select parameters and operating characteristics in force for the initiator at the time the Reserve command is executed. This transfer of operating parameters is applicable to target devices which store mode information independently for different SCSI IDs. This mechanism allows an initiator to set the operating parameters of a target for the use of a copy master -- the third party device. The third party copy master may subsequently issue a Mode Select command to modify these parameters. Add the following new paragraph to the description of Third Party Release. (Section 8.1.14.3, Page 8-72 of SCSI-2 Draft Rev. 2.) If the third party bit is one, the target shall not modify the operating parameters used for commands received from the third party device even if the target implements the transfer of operating parameters with the third party Reserve command. To Be Supplied -- A new Appendix illustrating the sequences required to set up 3rd Party Copy operations under various circumstances.