This message is from the T13 list server.
A SAT study group teleconference call was held Friday, June 3, 2004 from 9:00AM to 10:00AM PDT. Bob Sheffield of Intel provided the audio bridge and the WebEx session. 1. Attendance Brad Besmer, LSI Dan Colegrove, HGST Jim Coomes, Seagate Rob Elliott, H-P Greg Elkins, Qlogic Mark Evans, Maxtor Jim Hatfield, Seagate Ken Hirata, Emulex Pat LaVarre, Iomega Steve Livaccari, IBM John Lohmeyer, LSI Nathan Marushak, Intel Curtis Nottberg, Emulex Samantha Ranaweera, LSI Bob Sheffield, Intel Kyle Sterling, Adaptec Curtis Stevens, WD Tim Symons, Adaptec 2. Project proposal The group reviewed and recommended modifications to the project proposal. The modifications will be included in 04-174r2. The goal is to have the next revision of the proposal available for review two weeks before the next T10 meeting. 3. Draft status Bob Sheffield updated the group on the status of a preliminary draft. Bob reported that he hoped to have a preliminary draft two weeks before the next T10 meeting so that the group could review the draft for discussion at the meeting. 4. Discussion The following reflects much of the other discussion that occurred during the teleconference (courtesy of notes from Bob Sheffield): SCSI ATA f/w revision bytes: how many should there be? Many implementations truncate ATA information in INQUIRY unnecessarily. There are bytes in INQUIRY that are available. ATA has more than 4 bytes of product revision. Can these spill into INQUIRY Vendor-Specific bytes? Should the vendor ID generated by the ATA/SCSI translation layer or from the ATA device? A combination creates illegal ID's. If we make it be from the translation layer, all vendors have to choose the same thing, but then it doesn't reference the actual drive. Do we need a passthrough to see the real stuff? There seems to be agreement we do, but we need consistent boilerplate stuff. Some ATA drives implement UI-64, but it is optional in ATA/ATAPI-7. A globally unique WWN helps with device-ID, but not with the vendor string. There are only a few globally unique names in the list that correspond to vendors. We could, perhaps, define a mapping between the vendor ID binary to a company-name string. Names need to be 8 bytes, so vendors would have to get T10 vendor-IDs. In practice there are more IDs than there are registered. A T10 vendor ID may be obtained at www.t10.org/members/vendorid.htm. Unregistered vendors should register. OUIs are binary as described in ISO/IEC document 13213 1994 (also see ATA/ATAPI-7, page 137). There are no leading blanks in T10 vendor IDs. Reserving a string reserves upper and lower cases. Look in Annex-D in SPC-3 for examples. This doesn't mean we don't have to handle non-OUI cases. Typically the model number is preceded by the vendor name in the ATA model number string in IDENTIFY DEVICE, but this is not consistent. Suggestion: use translation SW vendor ID, and go to IDENTIFY DEVICE data for the actual information. SW capable of parsing the data can display the entire field (including WWN if it's there). SW that doesn't handle this would just display that it's translated information rather than information from an actual disk. Firmware revision (real or not): It was recommended that this be dealt with by having a VPD page for the entire IDENTIFY DEVICE information. Information should generally not be cached but fetched from the device on-demand. INQUIRY asking for VPD data should always generate an IDENTIFY DEVICE request to an ATA drive. What about standard INQUIRY data? If there's nothing in the standard INQUIRY data that's dependent on the drive, then it doesn't need to generate an IDENTIFY DEVICE request to the drive. SCSI has an "INQUIRY DATA Changed" unit attention. The translation layer could post this anytime something disruptive happens with the device. In standard INQUIRY data, it would be appropriate to define a bit that says, "translated", kind of like the one that says enclosure or media changer. We could use a standard string in the vendor-specific data. We should spoof as much as we can. A drive should come through as a block storage device. How do you pass up the fact that a translation is going on, even though the host software isn't translation aware? Do we need to pass up something in the drive stream? A bit is good for translation-aware SW. We could do something in the firmware revision bytes to represent translation. It will be passed up to a display console, but won't affect software behavior. A suggestion was made for using the first 4 bytes. "SATL"? Rob Elliott would prefer to have this in the product identification field. Does anyone want to copy drive and vendor from the drive? Someone said "yes". Would relying on the version descriptor be enough? What if the vendor ID was translation software - product ID is "SAT xxxxx". xxxx is as many characters from the model number that fit. The revision string is the revision string. Problem: some may already start with SAT. We could use other characters. Do we need more passthrough than just IDENTIFY DEVICE? a - general ATA passthrough via a SCSI command b - for SMART (lots of sub-functions). Some return values & registers. We could provide a general PIO in/out passthrough to handle SMART. (16-byte or 8-byte?) Give it a task file that represent registers. This ends up being the equivalent of a host-to-device FIS - (with data-in is the corresponding device-to-host FIS?). Device Configuration Overlay (DCO): we could use a register passthrough for that. There's no comprehensive SCSI analog (e.g., one that can be used to change the capacity of the drive). Scope question: if we model passthrough IF on SATA (FISes), there are some vendor-specific PATA capabilities not handled by SATA. Do we limit the scope to what's meaningful to SATA? VPD page 83: we need to take OUI out of IDENTIFY if ATA supports it and put it into page 83 in SCSI. For optional ATA features (and pre-ATAPI-7 versions): we need to describe handling in cases where the features are or are not supported. At least to start with we'll deal with what's defined in ATA/ATAPI-7 and only consider dependencies on earlier versions of the ATA standards on a case-by-case basis. We need to spec the behavior if device reports it's an ATA/ATAPI-6 device. So we aren't saying it won't work with earlier versions, but it's out of the scope of our project. 5. Meeting schedule The next study group meeting will occur from 9:00AM to 1:30PM MDT, Tuesday, July 13, 2004 at the Doubletree World Arena Hotel in during the T10 meeting week in Colorado Springs, CO (see the www.t10.org for more information). Tentatively, a teleconference has been scheduled for Thursday, August 9, 2004 at 9:00AM PDT. Tentatively, a study group meeting is proposed to begin at 1:00PM MDT on Thursday, August 26 going through to 12:00PM MDT on Friday, August 27 at the Boulderado during the T13 meeting week in Boulder, CO.
