[T10] Question on wording of sanitize operation behiavior

Gerry Houlder gerry.houlder at seagate.com
Fri Sep 8 12:53:38 PDT 2017


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> 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] *On Behalf Of *Gerry
> Houlder
> *Sent:* Friday, September 8, 2017 9:38 AM
> *To:* T10 Reflector <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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20170908/f4039a2f/attachment.html>


More information about the T10 mailing list