[T10] ZBC-2 complications for obsoleting 6 byte MODE SELECT / MODE SENSE commands

Bill Martin bill.martin at samsung.com
Fri Aug 26 09:42:13 PDT 2022


I also agree that MODE SENSE == all versions of MODE SENSE including MODE SENSE (10). I am in agreement with the general directions expressed in this string about the process of obsolescence as well.

Bill Martin

Chair INCITS T10
Co-Chair SNIA Technical Council

Chair SNIA CMSI

NVMe Board of Directors
SSD I/O Standards
Samsung Semiconductor, Inc.
Cell (408) 499-1839

From: t10-bounces at t10.org [mailto:t10-bounces at t10.org] On Behalf Of Knight, Frederick
Sent: Monday, August 22, 2022 6:08 AM
To: Ralph Weber <Ralph.Weber at wdc.com>; T10 Reflector <t10 at t10.org>
Subject: Re: [T10] ZBC-2 complications for obsoleting 6 byte MODE SELECT / MODE SENSE commands

I agree with Curtis.

MODE SENSE == all versions of MODE SENSE, which includes (6), (10), (20), (25), etc ... (ignore the fact that 20 and 25 don't even exist; the point is that the naked notation references ALL versions of that command - no matter WHAT they are).  And, so I see no problem if, instead of 2 variants, there just happens to be 1 variant that is documented in SPC (the (10) variant).

Anyone that doesn't know what it is, and therefore does a search of "MODE SENSE" to find out what it is - will STILL FIND IT.

And, FWIW - this statement (from SPC):
If there is more than one CDB length for a particular command (e.g., MODE SENSE(6) and MODE
SENSE(10)) and the name of the command is used in a sentence without any CDB length descriptor (e.g.,
MODE SENSE), then the condition described in the sentence applies to all CDB lengths for that command.

Doesn't use MODE SENSE for the example in SBC, it uses ORWRITE (16)/(32).

I also agree with what Ralph said.  Us standards folks will understand the significance and meaning of this action (read SPC-5 if you want the MODE SENSE (6) documentation), but some implementers may see it as a prohibition against implementing it at all - and possibly cause them to discover some issues we aren't even aware of (old BIOS issues maybe?). Someone might think they must remove MODE SENSE (6) from their code in order to be SPC-6 compliant.  How many brand new implementations are there these days anyway.

Personally, my opinion is that the ship has sailed on this idea (we should have done all (6) retirements at the same time - back years ago).  Given the state of SCSI implementations, we're likely to cause more confusion by doing this than if we just leave it alone (and leave MODE SENSE (6) documented).  What problem are we fixing by removing it?  It is optional, and anyone that doesn't want to implement it is not required to implement it.

If it is so important to do this, then consider using the RESERVE(6)/(10) and RELEASE(6)/(10) commands as a model (SPC-6).  FWIW - we don't document those CDBs anymore, but we DO still have a whole section dedicated to them.  After describing a few "exceptions", we say:

In all other cases, the device server shall process a RESERVE(6) command, RESERVE(10) command,
RELEASE(6) command, or RELEASE(10) command as defined in SPC-2.

                Fred


From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Ralph Weber
Sent: Thursday, August 4, 2022 7:58 PM
To: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>
Subject: Re: [T10] ZBC-2 complications for obsoleting 6 byte MODE SELECT / MODE SENSE commands

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


With Respect To the following September CAP Agenda Item:
7.1.2    SPC-6 SBC-5 Obsolete the 6 byte MODE SELECT and MODE SENSE commands (22-063r2) [Houlder]

The WD Engineering review concluded that the real world will see almost zero difference whether or not the proposal is implemented.

The only exception to the above being the plethora of complaints about "taking away valuable commands."

Yes, we standards wonks know what "obsolete" means, but we are the exceptions, not the rule.

To be sure, the WD engineers lauded the spirit behind the proposal, but these good vibes gave no measurable boost in support for the proposal, which was dragged down by remembrances of the READ(6) actions.

FWIW I have been instructed to vote "Abstain" on any approval motions for 22-063r2 or its progeny.

All the best,
.Ralph

From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Gerry Houlder
Sent: Thursday, August 4, 2022 4:58 PM
To: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>
Subject: Re: [T10] ZBC-2 complications for obsoleting 6 byte MODE SELECT / MODE SENSE commands

I agree with you Curtis. In that case, I should not be changing any of the base MODE SELECT and MODE SENSE references in SPC-6 and SBC-5 either. Unfortunately, that is not the direction I was given at previous T10 meetings. Can we do a straw poll on reflector about whether to change the direction to "change all instances of bare MODE SELECT and MODE SENSE to append (10) "?
________________________________
From: Ballard, Curtis C (HPE Storage) <curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com>>
Sent: Thursday, August 4, 2022 4:47 PM
To: Gerry Houlder <gerry.houlder at seagate.com<mailto:gerry.houlder at seagate.com>>; T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>
Subject: RE: [T10] ZBC-2 complications for obsoleting 6 byte MODE SELECT / MODE SENSE commands





This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.



Gerry,



I don't see why this is a problem for ZBC.  As you point out in bold - the T10 documentation style is that a command that has multiple sizes when referenced without an indication of size refers to all versions.  If there are MODE SENSE and/or MODE SELECT commands without references today those refer to all sizes.  If we obsolete one size those still refer to all sizes.



Curtis Ballard

Hewlett Packard Enterprise



From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Gerry Houlder
Sent: Thursday, August 4, 2022 10:53 AM
To: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>
Subject: [T10] ZBC-2 complications for obsoleting 6 byte MODE SELECT / MODE SENSE commands



I have observed that ZBC-2 rev. 13 references SPC-6. If my proposal to obsolete the 6 byte MODE SELECT and MODE SENSE commands is accepted, there are 4 instances of MODE SELECT or MODE SENSE that do not include a number of bytes (e.g., (6) ) after them. These would have to be changed to add (10) after them. ZBC-2 is in an advanced state of trying to be published (I think new proposals are not being accepted at this time?). How to we resolve this problem? i think the ZBC-2 changes must be included in my proposal to obsolete the 6 byte commands.



A much simpler approach is to allow MODE SELECT and MODE SENSE without any number of bytes on it to remain. Per existing rules, that reference would still apply to a 10 byte version of those commands and greatly simplify the fallout changes to other standards. I would like to start a reflector discussion on that approach in hopes of coming to a conclusion for that option at the September T10 meeting



SAT-6 will have a much larger set of changes to include SPC-6, but since that is just in the formative stages that can be addressed by a separate proposal.



SPL-5 rev. 15 only references SPC-5, so that would not be affected. A future SPL-6 would have 45 instances of MODE SELECT or MODE SENSE that would need a (10) added.



SAM-6 only references SPC-5 so that would not be affected. A future SAM would have one instance of MODE SELECT that needs to change to MODE SELECT (10).



SAS 4.1 has no instances of MODE SELECT or MODE SENSE so is not affected and future revisions should also not be affected.



I haven't analyzed the other standards, but they currently reference SPC-5 have would have no immediate changes.



Seagate Internal


Seagate Internal


Seagate Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.t10.org/pipermail/t10/attachments/20220826/ff0a3a1a/attachment.html>


More information about the T10 mailing list