[T10] T10 Document Number Assigned (T10/15-288r0)

Curtis Stevens curtis.stevens at wdc.com
Tue Nov 17 16:43:29 PST 2015


The ZBC editor likes Joes approach way better…



-------------------------------------------------
Curtis E. Stevens
Director, Standards & Features Technology
3355 Michelson Dr. #100
Office: 1-1041
Irvine, Ca. 92612

Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: Curtis.Stevens at WDC.com<mailto:Curtis.Stevens at WDC.com>

Remember, you may only be blamed for something if you are actually doing something.

From: t10-bounces at t10.org [mailto:t10-bounces at t10.org] On Behalf Of Joe Breher
Sent: Tuesday, November 17, 2015 3:11 PM
To: Gerry Houlder <gerry.houlder at seagate.com>
Cc: T10 org <t10 at t10.org>
Subject: Re: [T10] T10 Document Number Assigned (T10/15-288r0)

inline…

Joe Breher
Storage Architecture Technologist
Standards Setting Organization
San Jose Research Center
HGST, a Western Digital company
(478) 2-Breher
(478) 227-3437

[cid:image001.png at 01D12157.1EE99170]

On Nov 17, 2015, at 3:51 PM, Gerry Houlder <gerry.houlder at seagate.com<mailto:gerry.houlder at seagate.com>> wrote:

So my point is that those descriptions SHOULD NOT EXCLUDE describing the states that are missing. This is just as much an issue for those commands as it is for a sanitize operation. That would cover all the cases except the crypto erase case with ZNR=1, which still seems to have some exception cases to be described individually. I would suggest that those exception cases should be defined in the Sanitize Operation clause of ZBC (again, with a eye of keeping the messiest zoned device details within ZBC) and SBC-4 should just reference ZBC to get the details of how the ZNR bit affects zoned devices during sanitize operations.

Yeah, I guess that could work. Personally, I still like my approach.

In cases other than sanitize, the issue seems settled to me. Those commands have no effect on zones in those states (i.e. with those zone conditions). Accordingly, it makes sense that they are omitted from the command descriptions. Note that ZBC sanitize uses the term of art ‘perform the equivalent of the XXX command’. This seems to be cloned from PREVENT ALLOW MEDIUM REMOVAL, where it is used to mandate that “… the equivalent of a PREVENT ALLOW MEDIUM REMOVAL command with the PREVENT  field set to 00b shall be processed for each the I_T nexuses associated with the persistent reservation or registrations being preempted…” This is the only other place that this term of art is employed within SBC-4 (r08). Further, that would be a more significant rewrite.

Looks like the wisdom of the larger group is required to select. Are you going to draft a competing proposal?



I minor detail with your existing proposal is that you are trying to reference a clause number in ZBC from text that will be in SBC-4. The best you can do in this case is reference ZBC, not a specific clause. If you really need to reference a specific ZBC clause, then the added text will have to go into ZBC somehow.

Ah! Ya caught me!

(yes, I see it now - thanks)



On Tue, Nov 17, 2015 at 4:39 PM, Joe Breher <Joe.Breher at hgst.com<mailto:Joe.Breher at hgst.com>> wrote:
Thanks for your comments Gerry.

The problem I see with your approach is that RESET WRITE POINTER and FINISH ZONE with the ALL bit set to one explicitly exclude zones in the states (zone conditions) indicated by the analysis in my proposal. This is exactly the gap I am trying to close.

Joe Breher
Storage Architecture Technologist
Standards Setting Organization
San Jose Research Center
HGST, a Western Digital company
(478) 2-Breher
(478) 227-3437<tel:%28478%29%20227-3437>

<HGST_Logo_email.png>

On Nov 17, 2015, at 3:21 PM, Gerry Houlder <gerry.houlder at seagate.com<mailto:gerry.houlder at seagate.com>> wrote:

I would like to suggest another approach.

The sanitize description in SBC-4 tried to avoid describing a complete, state-by-state sanitize effect for ZBC devices by leveraging existing ZBC behavior (e.g., "..perform the equivalent of ...") that we though already described all the desired cases. It turns out that Joe believes there are holes in these descriptions that make the end result unclear for some initial states.

I would rather see a proposal that fills in the holes in the descriptions of:

  1.  the RESET WRITE POINTER command with the ALL bit set to one; and
  2.  the FINISH ZONE command with the ALL bit set to one.
This keeps the messy ZBC related details contained with in ZBC, rather than exporting more ZBC details to SBC-4. In addition, some unclear behavior for the above commands with the ALL bit set to one will be clarified, which would be a good thing even if a sanitize is not being performed.

On Tue, Nov 17, 2015 at 2:32 PM, Joe Breher <Joe.Breher at hgst.com<mailto:Joe.Breher at hgst.com>> wrote:
At last week’s plenary, the assembly decided that a proposal was needed to resolve one of HGST’s post-integration comments. 15-288r0 is that proposal. Changes are limited to SBC-4. However, the proper venue for discussion is likely the next ZBC webex.

Joe Breher
Storage Architecture Technologist
Standards Setting Organization
San Jose Research Center
HGST, a Western Digital company
(478) 2-Breher
(478) 227-3437<tel:%28478%29%20227-3437>

<HGST_Logo_email.png>


Begin forwarded message:

From: T10 Document Administrator <roweber at ieee.org<mailto:roweber at ieee.org>>
Subject: Re: Re: T10 Document Number Assigned (T10/15-288r0)
Date: November 17, 2015 at 1:09:50 PM MST
To: <joe.breher at hgst.com<mailto:joe.breher at hgst.com>>


2015/11/17 12:10:10

Your request to upload a file or files to the T10 site has been accepted.

Your PDF file will be posted at:

  http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-288r0.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.t10.org_cgi-2Dbin_ac.pl-3Ft-3Dd-26f-3D15-2D288r0.pdf&d=CwMGaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=TxI1DC4HavpWBdSmUqvdNvSwgOklhaW328zLt5AOpPM&m=zLOXuG7kA6ZmCUsnrFTMtpoi-mKYYsluutUevvPKrvo&s=2crZbJ7y-SiIzzMFj_9dNmqw067Kbx6Y4hNHVR4-V5A&e=>

Source File(s) that will be archived are:

  15-288r0.fm<https://urldefense.proofpoint.com/v2/url?u=http-3A__15-2D288r0.fm_&d=CwMGaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=TxI1DC4HavpWBdSmUqvdNvSwgOklhaW328zLt5AOpPM&m=fOHjY3Pi7bv_GcOoYh5uXFKVIlUHGXzWm0iZMOBRjAs&s=sUYLCn9R_sUtaZuU83bKpo_b9ZHY1_AlX7BImB3Uo7c&e=> will be archived as 15-288r0.fm<https://urldefense.proofpoint.com/v2/url?u=http-3A__15-2D288r0.fm_&d=CwMGaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=TxI1DC4HavpWBdSmUqvdNvSwgOklhaW328zLt5AOpPM&m=fOHjY3Pi7bv_GcOoYh5uXFKVIlUHGXzWm0iZMOBRjAs&s=sUYLCn9R_sUtaZuU83bKpo_b9ZHY1_AlX7BImB3Uo7c&e=>

Normally, the posting/archiving process takes about 30 minutes.

Please contact Ralph Weber <roweber at ieee.org<mailto:roweber at ieee.org>>
should you need further assistance.

HGST E-mail Confidentiality Notice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited.  If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.

_______________________________________________
T10 mailing list
T10 at t10.org<mailto:T10 at t10.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.t10.org_mailman_listinfo_t10&d=CwICAg&c=IGDlg0lD0b-nebmJJ0Kp8A&r=TxI1DC4HavpWBdSmUqvdNvSwgOklhaW328zLt5AOpPM&m=zLOXuG7kA6ZmCUsnrFTMtpoi-mKYYsluutUevvPKrvo&s=t2zinkjeahxcCNwJSluSuRYo3idt4EocsehlR6ljVBw&e=


HGST E-mail Confidentiality Notice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited.  If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.


HGST E-mail Confidentiality Notice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or legally privileged information of HGST and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited.  If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20151118/5bbdc7c1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4274 bytes
Desc: image001.png
URL: <http://www.t10.org/pipermail/t10/attachments/20151118/5bbdc7c1/attachment-0001.png>


More information about the T10 mailing list