READ (6), WRITE (6), et al.

Elliott, Robert (Server Storage) Elliott at
Wed Dec 8 22:39:22 PST 2010

Formatted message: <a href="">HTML-formatted message</a>

In SBC-3, I favor obsoleting the 6-byte versions but would keep the 10-byte
versions.  The 6-byte commands have too many special cases: transfer length
of 0, special DIF rules, lack of force-unit-access and group support, etc.  
implementing and testing these consumes development time, test time, and code
space in targets and SAT layers.
Remember that "obsolete" just means "defined in a previous version of the
standard."  Targets can continue to offer these commands as long as there is
a perceived need.  If another new feature like DIF comes along, though, the
standard won't advise how to handle the obsolete commands in light of the new
feature.  As documentation becomes harder to find and targets start dropping
obsolete features, initiators should feel pressure to stop using them.	This
can take years (has usage of the Format Device mode page and Rigid Disk
Geometry mode page been eradicated yet?).
SBC-2, published over 5 years ago, included the recommendations to use
10-byte rather than 6-byte commands.  It also had DIF support rules.
Maybe SBC-4 and SPC-5 can exorcise the 10-byte commands and fixed format
sense data.
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Matthew Jacob
Sent: Wednesday, December 08, 2010 5:28 PM
To: Mark Evans
Cc: t10 at
Subject: Re: READ (6), WRITE (6), et al.
I see no real advantage in obsoleting commands that have been well known
since 1984 *and* remain in active use today. For the random few people still
booting microVaxen, or even SparcStation 1 (I know someone who still uses one
as a desktop system), why shouldn't the be able to use modern (through
appropriate electrical dongles) storage?
Will drive vendors *really* reap *substantial* cost savings with this?
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of
Sam.Pappal at
Sent: Wednesday, December 08, 2010 6:01 PM
To: mj at; Mark.Evans at
Cc: t10 at
Subject: RE: READ (6), WRITE (6), et al.
Some legacy hosts currently in wide use and perhaps some drivers try Read 6
during boot and operation as part of failure recovery. These hosts will hang
there and may require reboot if Read 6 is not supported by the drive. ..  can
become a deadly embrace in my experience.
Systems Engineering Staff
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Mark Evans
Sent: Wednesday, December 08, 2010 4:52 PM
To: t10 at
Subject: READ (6), WRITE (6), et al.
As capacities in storage devices have increased, there has been much
discussion about how several commands do not have the capability to access or
reflect the new capacities.  For example, READ (6), READ (10), READ (12),
WRITE (6), WRITE (10), WRITE (12), and several other commands can not address
LBAs for storage devices having capacities greater than about 2.2 TB, but
there are devices today exceeding this capacity and the trend only goes up
and to the right.  In addition, READ (6) and READ (10) are currently
mandatory commands in SBC-3.  There is even a note in the table listing the
commands that reads, "Application clients should migrate from the READ (6)
command to the READ (10) command and from the WRITE (6) command to the WRITE
(10) command."
I think that, at the very least we should make READ (6) and READ (10)
optional and replace the note with, "Application clients should migrate from
the READ (6), READ (10), and READ (12) commands to the READ (16) command and
|from the WRITE (6), WRITE (10), and WRITE (12) command to the WRITE (16)
command."  I go so far as recommending that all commands incapable of dealing
with greater than 2.2 TB be made obsolete, though I could see waiting to do
this until SBC-4.  Thoughts?  Comments?
Please feel free to call or send an email to me with any comments or
questions that you have about this stuff.
Mark Evans
Western Digital Corporation
5863 Rue Ferrari
San Jose, CA 95138
Email: mark.evans at

More information about the T10 mailing list