[T10] Question on wording of sanitize operation behiavior

Bill Martin bill.martin at samsung.com
Mon Sep 11 09:25:34 PDT 2017

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>>
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>>,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>>,Bill Martin <bill.martin at samsung.com<mailto:bill.martin at samsung.com>>,Curtis Stevens <curtis.stevens at wdc.com<mailto: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 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] On Behalf Of Ballard, Curtis C (HPE Storage)
Sent: Friday, September 08, 2017 1:17 PM
To: Gerry Houlder <gerry.houlder at seagate.com>
Cc: T10 Reflector <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.


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>>
Cc: T10 Reflector <t10 at t10.org<mailto: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>> wrote:

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


From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> [mailto:t10-bounces at t10.org<mailto:t10-bounces at t10.org>] 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>>
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.

More information about the T10 mailing list