[t13] Minutes of SAT teleconference

Evans, Mark Mark_Evans at maxtor.com
Mon Jun 7 06:02:15 PDT 2004


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.




More information about the T10 mailing list