LASER MAGNETIC STORAGE MEMO INTERNATIONAL COMPANY ______________________________________________________________________________ Optical Storage Division 16 September 1987 To: SCSI Standards Committee X3T9.2 Jeff Stai, Optical Sections Editor Western Digital Corporation From: Paul Boulay (303) 593-4323 Subject: Comments on Optical Sections of SCSI-2 Ref: X3T9.2/87-146 Revision 1. Overall, the referenced document represents a considerable improvement in the state of chapters 12, 13 and 15 of the draft SCSI-2 standard. This note suggests a few minor changes and poses some questions of the editor and the committee as a whole. 1.) Making use of the generic Direct Access descriptions is an acceptable idea in order to ensure consistency and to make the standard cost less to reproduce. I wonder if the definition of the BLANK CHECK error -- especially the previously unwritten block part -- would be objectionable to the representatives of the magnetic media firms. If a magnetic media has been formatted but not written is this a blank check situation? This situation is quite clear to those with experience with SCSI controllers for the usual sort of magnetic direct access devices but is sure to spawn confusion among those coming to the SCSI-2 standard without such experience. I suggest that we keep the definition of the BLANK CHECK condition back in chapter 15. It does not seem necessary to repeat all the text of the direct access read and write commands, rather, handle it on an exception basis. For instance, the read connand in section 15 could say: "The Read command requests that the target transfer data from the media to the initiator. See the Direct Access Read command description (section 8.1.9.) for definitions of the fields in this command and the error conditions common to Direct Access devices and Optical Memory devices. "In addition to the common error conditions, Optical Memory devices shall report as follows: "Condition Sense Key ------------------------------------- -------------------------------- Attempt to read a blank or previously BLANK CHECK unwritten block" 2.) Mandatory Commands for WORM and RO devices (sections 12 and 13). I believe that these commands should be required in all SCSI-2 Optical Devices: Inquiry 12h Read 28h Read Capacity 25h Release 17h (Unit and 3rd Party only) Request Sense 03h Reserve 16h (Unit and 3rd Party only) Send Diagnostic 1Dh (Self Test only) Test Unit Ready 00h Write 2Ah (but not for RO devices) Without these commands sections 12 and 13 are a throwback to SCSI-1. One of the initial reasons for creating the SCSI-2 effort was to formalize the CCS principles and apply then across the board. If any of the listed commands remain optional a complying SCSI-2 WORM or RO device could be built that does not properly support self configuring systems. This is in conflict with the stated goal of SCSI-2. 3.) If there is to be a separate section in the SCSI-2 document for CD-ROM is there any need for the RO device type?? 4.) In the rewrite of the Media Scan command the statement that the implementation of Reverse Scan Direction is optional has been dropped. Why? This feature may be very cumbersome to implement in some devices or may result in unreasonable delays. There is ample precedent for stating in the standard that implementation of command features is optional - for instance, extent reservations. I believe that the statement that allows for optional implementation of this bit should be retained. (The same argument applies to the ASA bit but since that is defined as advisory the implementation of a binary search or other "advanced' algorithm can be interpreted as optional.) 5.) In the last paragraph of the Media Scan command, the description of the Number of Blocks to Scan field, a "may" was changed to "shall". I think "may" is appropriate unless "... or until the Media Scan criteria is satisfied" is added. 6.) In the Mode Select description of enable blank check (EBC) of zero, delete "or an UPDATE BLOCK command" and add a new sentence: "An UPDATE BLOCK command shall not result a CHECK CONDITION with a BLANK CHECK Sense Key due to block(s) not being previously written." There may be a better way to say this without the double negative. 7.) The definition of Read Updated Block (1st paragraph) seems to preclude transfer of generation zero data. How about: "The READ UPDATED BLOCK command requests that the target transfer data for specified generations of a logical block(s) to the initiator." The order in which the several generations of data for a single block is returned is not clear from the 15.1.8.1 description. The problem, for me, stems from the two definitions of "increasing generation addresses" as given by the "Latest" bit. For the Single Generation Data option (15.1.8.2), what is the desired response if, for some block, the requested generation does not exist? Is this a BLANK CHECK ?? For the Maximum Generation Data Block option (15.1.8.3) is the transfer length field an allocation length?? In this mode the generation address field is -- Ignored? Reserved?? 8.) In the Update Block command, the new text at the end of the first page, "This standard does not define ..."; if EBC is one the required result is defined as a BLANK CHECK. Isn't it?? IF EBC is zero, the statement is probably true due to the several ways to implement the Update Block. In response to the editors question about the rationale for the Recovered Error indication on reading an updated block. This came out of the Optical working group meeting in Colorado Springs about 9 months ago. For WORM devices, there's an implicit guarantee of unalterability. The Update Block invalidates this assertion without a mandatory reporting of transfer of modified data. 9.) In the Verify and Write and Verify commands, why is the verification criteria given as vendor unique if no explicit Verify parameters are received. What's wrong with specifying this as the same criteria as a read. 10.) Write command, EBP description. Why not handle this the same as suggested for Read above (1).