Format Unit SI bit

Gerry Houlder gerry.houlder at seagate.com
Tue Jun 7 12:06:08 PDT 2011


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1106075_f.htm">HTML-formatted message</a>

If you want a more precise definition of your sanitize process, consider
implementing the newly created SANITIZE command instead. This certainly
eliminates most of the uncertainty you are concerned about. The command can
be seen in SBC-3 rev. 27 or proposal 11-011 (latest revision). The hope is
that the features described in this command will meet the needs of everyone
planning to inplement a sanitize function instead of using the SI bit.
On Tue, Jun 7, 2011 at 1:27 PM, Jon Haswell - SISA <
jon.haswell at sisa.samsung.com> wrote:
> I would agree with your last comment, re needing to clarify (b). Wording
> such as ‘take precedence over’  is very ambiguous. To me ‘taking precedence
> over’ implies it overrides other settings if they conflict, but any
conflict
> is vendor unique/unspecified so nobody can rely on what will or will not be
> overridden.
>
>
>
> We are currently implementing it so we do the security initialize first and
> then we implement everything else, we actually have no conflicts so we
> implement every other function/feature requested after the initialize is
> completed.
>
>
>
> I would prefer to see some statement that is definitive such as, ‘When the
> SI bit is specified all other options are ignore’ if that is really what is
> intended. Or if not let’s get specific as we do in other commands/mode
pages
> where we define what bits are honored/ignored where we have multiple bits
> that conflict/interact.
>
>
>
> Thanks
>
>
>
> Jon Haswell
>
> SSD Development
>
> Office  408 544 5869
>
> Cell	   408 472 2495
>
>
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Mark
> Evans
> *Sent:* Tuesday, June 07, 2011 10:39 AM
> *To:* Penokie, George; Gerry Houlder; T10 Reflector
>
> *Cc:* Truong Nguyen - SISA
> *Subject:* RE: Format Unit SI bit
>
>
>
> Hi George,
>
>
>
> There are just too many “shalls” in the definition for the bit set to one
> for this to be as open-ended as you describe:
>
>
>
> a)	 …the device server shall attempt to write the initialization
> pattern to all areas of the medium including those that may have been
> reassigned (i.e., are in a defect list)…;
>
> b)	…An SI bit set to one shall take precedence over any other FORMAT
> UNIT CDB field…; and
>
> c)	 …the initialization pattern shall be written using a security
> erasure write technique….
>
>
>
> Though I’ll admit that item (c) is certainly vendor specific, I don’t see
> where there is even a hint that the target device will end up being
“totally
> inoperable”.
>
>
>
> Gerry, I can see now that all of the information in the command and
> parameter data could be used if the logical unit was to perform the
security
> initialize function and then finish with a normal format operation.  We
> don’t say this anyplace, but this condition could fall into George’s list
of
> vendor specific behavior.
>
>
>
> All of that written, I still think we need to clarify item (b).  I now
> think that what was meant is:  “…the security initialize function shall
take
> precedence over any other function specified by the FORMAT UNIT command.”
> To me this means that you have to do the security initialize stuff first,
> then whatever else you do is vendor specific.
>
>
>
> Please feel free to call or send an email to me with any comments or
> questions that you have about this stuff.
>
>
>
> Regards,
>
>
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose, CA 95138
> Email: mark.evans at wdc.com
> ------------------------------
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of
*Penokie,
> George
> *Sent:* Tuesday, June 07, 2011 9:02 AM
> *To:* Gerry Houlder; T10 Reflector
> *Cc:* Truong Nguyen - SISA
> *Subject:* RE: Format Unit SI bit
>
>
>
> You are both right and wrong.
>
>
>
> What happen when the SI bit is set depends on the customers specification.
> Is some cases the intent may that the device be totally inoperable (think
> the helicopter and all electronics need to be destroyed). In less radical
> conditions the drive may come back usable with data scrubbed off.
>
>
>
> At the time this was put in there was no agreement by the committee as to
> how scrubbed the data had to be, again that was intended to be left up to
> the customers specification.
>
>
>
> Bye for now,
> George Penokie
>
> LSI Corporation
> 3033 41st St. NW
> Suite 100
> Rochester, MN 55901
>
> 507-328-9017
> george.penokie at lsi.com
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Gerry
> Houlder
> *Sent:* Tuesday, June 07, 2011 10:18 AM
> *To:* T10 Reflector
> *Cc:* Truong Nguyen - SISA
> *Subject:* Re: Format Unit SI bit
>
>
>
> I think Mark's interpretation is too broad. The SI bit is intended to
> trigger a vendor specific security initialize feature. Things the device
has
> to do to implement this take precedence over other bits that might specify
> conflicting demands. However things that specify the required final format
> (e.g., logical block size, FMTPINFO) and whether existing defect lists are
> included or not (e.g., FMTDATA, CMPLST, DEFECT LIST FORMAT, defect list
> length) should still be obeyed. If an initialization pattern is specified,
> that should be the pattern left on the media after the security initialize
> is complete. The SI bit probably affects how defective areas (i.e., areas
> excluded from the user data area) are treated, but should not cause the
> device to ignore instructions about which areas are to be handled as
> defective areas.
>
> On Fri, Jun 3, 2011 at 10:56 AM, Mark Evans <Mark.Evans at wdc.com> wrote:
>
> Hi Truong,
>
>
>
> The SI bit was added into the INITIALIZATION PATTERN DESCRIPTOR for the
> FORMAT UNIT command in SBCr-05 based on proposal 96-186R1.  As you wrote
the
> definition of the bit was modified slightly in SBC-r06 as the result of
> discussion at the SCSI working group meetings in October of 1996.  The
> definition of the SI bit has not been changed since that time.
>
>
>
> What I think we really intended the new wording to mean is, “If the SI bit
> its set to one, then the device server shall ignore:
>
>
>
> a)	   the FMTPINFO field;
>
> b)	  the FMTDATA bit;
>
> c)	   the CMPLST bit;
>
> d)	  the DEFECT LIST FORMAT field;
>
> e)	   all of the bits and fields in the parameter list header, except
> the IMMED bit; and
>
> f)	    any defect list data.
>
>
>
> Others may correct me if I’m wrong.  You know who you are, and I’m sure you
> will – ha!
>
>
>
> Please feel free to call or send an email to me with any comments or
> questions that you have about this stuff.
>
>
>
> Regards,
>
>
>
> Mark Evans
> Western Digital Corporation
> 5863 Rue Ferrari
> San Jose, CA 95138
> Email: mark.evans at wdc.com
> ------------------------------
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Truong
> Nguyen - SISA
> *Sent:* Thursday, June 02, 2011 5:54 PM
> *To:* t10 at t10.org
> *Subject:* Format Unit SI bit
>
>
>
> In SBC3r27, in the Format Unit initialization pattern descriptor subclause
> 5.3.2.3, there is a statement regarding the SI bit precedence:
>
>
>
> "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB
> field."
>
>
>
> What is this statement supposed to mean specifically?
>
>
>
> It seems as though the statement was added some time ago in SBCr6:
>
>
>
> ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm
>
>
>
> "Clarified SI by adding the statement An SI bit set to one shall take
> precedence over any other FORMAT UNIT field."
>
>
>
> I could not find any proposals associated with the modification.
>
>
>
>
>
> Thanks,
>
>
>
> Truong Nguyen
>
>
>
> Samsung Information Systems America
>
>
>



More information about the T10 mailing list