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

James C Hatfield james.c.hatfield at seagate.com
Wed Nov 18 10:08:09 PST 2015


For comparison, ZAC describes the interaction in this way. Perhaps ZBC
could have similar language ?
==========================================================
4.7.6 Interactions with the Sanitize Device feature set

If a device that supports the Host Aware Zones feature set (see 4.3)
or the Host Managed Zones feature set (see 4.4) also supports the
Sanitize Device feature set (see ACS-4), then the additional requirements
described in this subclause apply.

The ZONED NO RESET bit shall be supported as described in ACS-4 for
each of the following commands that are supported:
a) the CRYPTO SCRAMBLE EXT command (see ACS-4);
b) the BLOCK ERASE EXT (see ACS-4) command; and
c) the OVERWRITE EXT command (see ACS-4).

A CRYPTO SCRAMBLE EXT command, BLOCK ERASE EXT command, or OVERWRITE EXT
command affects all zones as follows:
a) the specified sanitize operation is performed as specified in ACS-4
   for each Conventional zone (see 4.6.2);
b) the specified sanitize operation is performed as specified in ACS-4
   for each write pointer zone (see 4.6.3)
   and shall include processing of the ZONED NO RESET bit as described in
   ACS-4 if a sanitize operation:
   A) is successful; or
   B) fails and:
      a) the Failure Mode Policy value (see ACS-4) allows successful
         processing of a SANITIZE STATUS EXT command with the
         CLEAR SANITIZE OPERATION FAILED bit set to one; and
      b) a failed sanitize operation is followed by a SANITIZE STATUS EXT
         command with the CLEAR SANITIZE OPERATION FAILED bit set to one;
   and
   c) if the Zone Condition is READ ONLY or OFFLINE before the specified
      sanitize operation is performed, the Zone Condition shall not change
      as a result of the specified sanitize operation being performed.

<<< note: 'c', above will be modified to split the READ ONLY and OFFLINE
<<<         cases to separate bullets, as their requirements are different:
<<<         READ ONLY can transition to OFFLINE as a result of Sanitize.

An OVERWRITE EXT command that completes without an error modifies the
substitute data pattern (see 4.6.3.2.3 and 4.6.3.3.3).
==========================================================

Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....: 720-684-2711
   cell...: 720-771-8914

On Tue, Nov 17, 2015 at 5:43 PM, Curtis Stevens <curtis.stevens at wdc.com>
wrote:

> 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
>
>
>
> 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
>
>
>
>
>
> On Nov 17, 2015, at 3:51 PM, Gerry Houlder <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> 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
>
>
>
> <HGST_Logo_email.png>
>
>
>
> On Nov 17, 2015, at 3:21 PM, Gerry Houlder <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> 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
>
>
>
> <HGST_Logo_email.png>
>
>
>
> Begin forwarded message:
>
>
>
> *From: *T10 Document Administrator <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>
>
>
>
>
> 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>
> 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
>
> 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.
>
> _______________________________________________
> T10 mailing list
> 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=8mNfn1gTL7YQs9S_a4U_7b-WpO2_x-7ODMYXVic49hQ&m=0SRSFuUDVJf9eOkjUHmDYrJqjxCM5LJRDUXyPxBT4Cs&s=Y8TCnwG-iqNTRu_1mtcszBnpEEu_NW4n-xTEBsOLEHU&e=
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20151118/20e5abf2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4274 bytes
Desc: not available
URL: <http://www.t10.org/pipermail/t10/attachments/20151118/20e5abf2/attachment-0001.png>


More information about the T10 mailing list