[T10] Question on wording of sanitize operation behiavior

John Geldman John.Geldman at taec.toshiba.com
Wed Nov 1 18:36:13 PDT 2017


Fred,



I agree that "Power Loss Expected" is a SAS message, however it is also:

a)      a defined SAM event;

b)      a defined SAM condition; and

c)       a defined SPC 'ASC and ASCQ assignment' for use in any transport that choses to use it, as in:



0Bh


08h


DZTPROMAEBKVF


WARNING - POWER LOSS EXPECTED




Looking at SBC3r36, I'm not quite sure how many places you suggest to put but the 4.11 c) usage seems clear without changes (we did work to pull the common elements up into c):


c) suspend the sanitize operation while processing the following conditions (see SAM-5):
A) a power on;
B) a hard reset;
C) a logical unit reset; or

D) a power loss expected;



while the 4.11 e) B) usage could have an additional reference:


B) a power loss expected condition <add SAM reference here> in which no power loss occurs within constraints defined by the applicable SCSI transport protocol standard (e.g., power loss timeout in SPL-3);



John



-----Original Message-----
From: Knight, Frederick [mailto:Frederick.Knight at netapp.com]
Sent: Wednesday, November 01, 2017 6:08 AM
To: Bill Martin <bill.martin at samsung.com>; John Geldman <John.Geldman at taec.toshiba.com>; Ballard, Curtis C (HPE Storage) <curtis.ballard at hpe.com>; Gerry Houlder <gerry.houlder at seagate.com>
Cc: T10 Reflector <t10 at t10.org>
Subject: RE: [T10] Question on wording of sanitize operation behiavior



"power loss expected" is a SAS message, and it does occur before power is actually lost (devices have some amount of time between getting the message and losing power).  It is also possible to get that message and never lose power.  In other words, "power loss expected" is transport dependent (you never get it on FC, or iSCSI for example).



Another thing to consider, is taking the "(see SAM-5)" text out of the introduction sentence (where it is hard to notice, and where it is hard to determine what it refers to), and move it directly after each phrase where it applies.  That will directly connect the phrase (e.g., logical unit reset) with the reference to SAM-5 where the terms are defined (and puts the reference where it will be easy to notice, and it will be easy to know which term it is intending to augment).



                Fred



-----Original Message-----

From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> [mailto:t10-bounces at t10.org] On Behalf Of Bill Martin

Sent: Monday, September 11, 2017 12:26 PM

To: John Geldman <John.Geldman at taec.toshiba.com<mailto:John.Geldman at taec.toshiba.com>>; Ballard, Curtis C (HPE Storage) <curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com>>; Gerry Houlder <gerry.houlder at seagate.com<mailto:gerry.houlder at seagate.com>>

Cc: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>

Subject: Re: [T10] Question on wording of sanitize operation behiavior



Forwarding to reflector for John.



Bill Martin

Chair INCITS T10

Co-Chair SNIA Technical Council

SSD I/O Standards

Samsung Semiconductor, Inc.

Cell (408) 499-1839



-------- Original Message --------

From: John Geldman <John.Geldman at taec.toshiba.com<mailto:John.Geldman at taec.toshiba.com<mailto:John.Geldman at taec.toshiba.com%3cmailto:John.Geldman at taec.toshiba.com>>>

Date: Sun, Sep 10, 2017, 11:05 PM

To: "Ballard, Curtis C (HPE Storage)" <curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com%3cmailto:curtis.ballard at hpe.com>>>,Gerry Houlder <gerry.houlder at seagate.com<mailto:gerry.houlder at seagate.com<mailto:gerry.houlder at seagate.com%3cmailto:gerry.houlder at seagate.com>>>

CC: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org<mailto:t10 at t10.org%3cmailto:t10 at t10.org>>>,Bill Martin <bill.martin at samsung.com<mailto:bill.martin at samsung.com<mailto:bill.martin at samsung.com%3cmailto:bill.martin at samsung.com>>>,Curtis Stevens <curtis.stevens at wdc.com<mailto:curtis.stevens at wdc.com<mailto:curtis.stevens at wdc.com%3cmailto:curtis.stevens at wdc.com>>>

Subject: RE: [T10] Question on wording of sanitize operation behiavior I can't post yet (just remembered about rejoining the reflector). Please repost this as I'll get another 'blocked' from the reflector software until Curtis/Bill gets to it. Sorry for the multiple repost request which will confuse this thread for a while.



As one of the guilty party authors of this text, I'll note that the term "a power loss expected" in 4.11.2 c D was quite intentional.



SCSI devices are not prescient. They cannot process an unexpected power loss. They can only find out about it after the return of power. So, it is only possible to process "a power loss expected", which is a SCSI event we can know about.



The terms in 4.11.2 e A&B were also carefully chosen. In what case of an actual power loss is there not a logical unit reset? Only if the power loss expected never comes.



In hindsight, I'd expect such much of our word play to have come from George, spurred on by a bunch of us. While we are often too clever with our words, they still seem right to me. At this point, I'd understand adding clarity via notes (good luck), but not changing the existing terms.



What am I missing?



John





John Geldman



Director, SSD Industry Standards

Toshiba America Electronic Components, Inc.

SSD Business Unit

2610 Orchard Parkway, San Jose, CA 95134

Cell: +1 (408) 824-4561







From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> [mailto:t10-bounces at t10.org] On Behalf Of Ballard, Curtis C (HPE Storage)

Sent: Friday, September 08, 2017 1:17 PM

To: Gerry Houlder <gerry.houlder at seagate.com<mailto:gerry.houlder at seagate.com>>

Cc: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>

Subject: Re: [T10] Question on wording of sanitize operation behiavior



Hmm having two Curtis' weigh in on the same thread does get a bit tricky.



I don't mind if people want to work on some clarification though we have to be careful to get any such clarification technically correct.  The sanitize shouldn't resume immediately after the power on event, it needs to wait for the completion of the logical unit reset, so just "after processing any conditions . . . " isn't quite precise enough.  SAM is pretty clear that the "power on" condition is over when the "hard reset condition" starts which ends before the "logical unit reset condition" starts.



Curtis



From: Gerry Houlder [mailto:gerry.houlder at seagate.com]

Sent: Friday, September 8, 2017 1:54 PM

To: Ballard, Curtis C (HPE Storage) <curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com%3cmailto:curtis.ballard at hpe.com>>>

Cc: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org<mailto:t10 at t10.org%3cmailto:t10 at t10.org>>>

Subject: Re: [T10] Question on wording of sanitize operation behiavior



I agree with your reasoning Curtis Ballard, but it is hard to explain this to folks outside of T10 attendees.



i would like to see item e) reworded like this:

e) resume performing the sanitize operation after processing any condition that suspended the sanitize operation;



This at least makes it clear that the sanitize operation is to be resumed after all of the listed conditions that may suspend the sanitize operation have completed. i would be happy to write a proposal along these lines unless there are objections.



On Fri, Sep 8, 2017 at 2:30 PM, Ballard, Curtis C (HPE Storage) <curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com%3cmailto:curtis.ballard at hpe.com>>> wrote:

Gerry,



There was some discussion along these lines during the development of that text.



"power on" versus "unexpected power loss":  A "power on" is a condition defined in SAM but there is no definition in SAM, SPC, or SBC for "unexpected power loss".  Every SCSI device that is power cycled ends up in the "power on" condition.  For many SCSI devices the power on condition is the first time the SCSI device is able to detect that a power cycle occurred.  The sanitize operation doesn't make much progress while the power is off but sometimes the SCSI device doesn't get to actually suspend the sanitize operation until the power on condition occurs.



Regarding resuming the sanitize, it does seem like there is a possibility that could be more clear but the "power on" condition is clearly defined in SAM as a condition which "shall" cause a hard reset and the hard reset is defined as "shall" cause a logical unit reset so the rules documented in SAM take you to a condition that causes the sanitize to resume processing.  That is the sequence that is expected and documented in both text and diagrams in SAM.  At power on:



1)      The power on condition occurs which causes;



2)      The hard reset condition which causes;



3)      The logical unit reset condition which is specified as a condition after which the sanitize operation is resumed



Curtis



From: t10-bounces at t10.org<mailto:t10-bounces at t10.org<mailto:t10-bounces at t10.org%3cmailto:t10-bounces at t10.org>> [mailto:t10-bounces at t10.org<mailto:t10-bounces at t10.org><mailto:t10-bounces at t10.org%3cmailto:t10-bounces at t10.org%3e>] On Behalf Of Gerry Houlder

Sent: Friday, September 8, 2017 9:38 AM

To: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org<mailto:t10 at t10.org%3cmailto:t10 at t10.org>>>

Subject: [T10] Question on wording of sanitize operation behiavior



A question has come up about the rule for resuming sanitize operation after a power on. This is text from SBC-4 clause 4.11:



While performing a sanitize operation, the device server shall:

   :

   :

   c) suspend the sanitize operation while processing the following conditions (see SAM-5):

      A) a power on;

      B) a hard reset;

      C) a logical unit reset; or

      D) a power loss expected;

   d) not suspend the sanitize operation while processing an I_T nexus loss;

   e) resume performing the sanitize operation after processing:

      A) a logical unit reset; or

      B) a power loss expected condition in which no power loss occurs within constraints defined by the applicable SCSI transport protocol standard (e.g., power loss timeout in SPL-3);

   :

   :

First question: Item c) in cludes "power on" as something that cuases sanitize to be suspended, but it seems unreasonable that a sanitize could be in process while power is off. Should this be replaced with "unexpected power loss"?.



Second question: Item e) lists the two items after which sanitize is resumed. Shouldn't this include "power on" as an event to resume from? I think it is too subtle for everyone to understand that a power on always generates a logical unit reset as part of the power on event. Note that we have separate Unit Attention events for "power on reset occurred", "SCSI bus reset occurred", and "bus device reset function occurred". A casual reader could presume that only when "bus device reset function occurred" is reported that the sanitize operation should resume, but this is not what we have intended during our T10 committee discussions.





_______________________________________________

T10 mailing list

T10 at t10.org<mailto:T10 at t10.org>

http://www.t10.org/mailman/listinfo/t10

Western Digital Corporation (and its subsidiaries) E-mail Confidentiality Notice & Disclaimer:



This e-mail and any files transmitted with it may contain confidential or legally privileged information of WDC and/or its affiliates, 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/20171102/c5ed66c3/attachment.html>


More information about the T10 mailing list