[T10] WRITE SAME and 0 LBA counts

George Penokie george.penokie at broadcom.com
Mon May 23 06:28:15 PDT 2016


One persons "editorial" change could be another persons "substantive"
change. That said the fact that this thread is as long as it is means to be
that any change in this area will require a proposal.

Bye for now,
George Penokie

Broadcom Limited
Attn: George Penokie
4109 Manor View Dr NW
Rochester , MN 55901

952-921-2495
george.penokie at broadcom.com <george.penokie at avagotech.com>

On Sun, May 22, 2016 at 5:30 PM, Black, David <david.black at emc.com> wrote:

> > That said, however, it would appear that the two quoted SBC-4 text
> > citations profoundly violate T10's "say it the same way everywhere"
> > strong recommendation (i.e., rule).
>
> Indeed they do ...
>
> > Therefore ...
> >
> > Although I cannot support adding "computed" anywhere, I see no reason
> > why the SBC-4 editor cannot step in, pick a single phrase to describe
> > the quantity, and cause that phrase to be used consistently.
> >
> > In the event that the SBC-4 editor decides to solicit guidance from this
> > reflector, my vote is for the wording with "contiguous" and "requested"
> > in it.
>
> I concur with this suggestion.
>
> Thanks, --David
>
> > -----Original Message-----
> > From: t10-bounces at t10.org [mailto:t10-bounces at t10.org] On Behalf Of
> Ralph
> > Weber
> > Sent: Saturday, May 21, 2016 7:34 AM
> > To: t10 at t10.org
> > Subject: Re: [T10] WRITE SAME and 0 LBA counts
> >
> > Looking only at the SBC-4 text fragments quoted by David Black, I can
> > find no place where adding the word "computed" will serve any purpose
> > other than an increase in confusion.
> >
> > That said, however, it would appear that the two quoted SBC-4 text
> > citations profoundly violate T10's "say it the same way everywhere"
> > strong recommendation (i.e., rule).
> >
> > One citation talks about "the number of contiguous logical blocks that
> > are requested to be unmapped or written".
> >
> > The other citation says "the number of logical blocks specified to be
> > unmapped or written".
> >
> > David can freely drop the "contiguous" and substitute "specified" for
> > "requested", but (when the case is put this plainly) I'll bet steam will
> > begin to emanate from George's ears (to name just one of the rule's
> > proponents).
> >
> > Therefore ...
> >
> > Although I cannot support adding "computed" anywhere, I see no reason
> > why the SBC-4 editor cannot step in, pick a single phrase to describe
> > the quantity, and cause that phrase to be used consistently.
> >
> > In the event that the SBC-4 editor decides to solicit guidance from this
> > reflector, my vote is for the wording with "contiguous" and "requested"
> > in it.
> >
> > All the best,
> >
> > .Ralph
> >
> > On 5/21/2016 12:08 AM, Sitsofe Wheeler wrote:
> > >
> > >
> > > On 19 May 2016 at 02:08, Black, David <david.black at emc.com
> > > <mailto:david.black at emc.com>> wrote:
> > >
> > >     As for the original question:
> > >
> > >     >When the spec says "number of logical blocks specified to be [...]
> > >     written" is this only in reference to the NUMBER OF LOGICAL BLOCKS
> > >
> > >     > passed in rather than the computed number of blocks to be
> written or is
> > there a choice over which is used
> > >     (i.e. the target can pick
> > >
> > >     > whether it errors or not if the computed blocks exceed the
> MAXIMUM
> > WRITE SAME LENGTH)?
> > >
> > >     Neither - my reading of the current SBC-4 text is that the limit
> > >     always applies to the number of blocks written by the command, but
> > >     a careful reading of the text is involved to reach that
> > >     conclusion.  Excerpts that follow are from 5.47 WRITE SAME (10) in
> > >     SBC-4 rev 10:
> > >
> > >     If the WSNZ bit is set to zero, then a NUMBER OF LOGICAL BLOCKS
> > >     field set to zero specifies that the number of
> > >
> > >     contiguous logical blocks that are requested to be unmapped or
> > >     written includes all of the logical blocks
> > >
> > >     starting with the LBA specified in the LOGICAL BLOCK ADDRESS field
> > >     to the last logical block on the medium.
> > >
> > >     Note the use of "specifies" in the first line.
> > >
> > >     If the number of logical blocks specified to be unmapped or
> > >     written exceeds the value indicated in the
> > >
> > >     MAXIMUM WRITE SAME LENGTH field(see 6.6.4), then the device server
> > >     shall
> > >
> > >     terminate the command with CHECK CONDITION status with the sense
> > >     key set to ILLEGAL REQUEST and
> > >
> > >     the additional sense code set to INVALID FIELD IN CDB.
> > >
> > >     Note the use of "specified" in the first line.
> > >
> > >     So, a NUMBER OF LOGICAL BLOCKS field set to zero specifies that
> > >     all of the logical blocks up to the end of the medium are to be
> > >     unmapped or written, and if that (computed) number of logical
> > >     blocks exceeds the MAXIMUM WRITE SAME LENGTH value, the required
> > >     result is CHECK CONDITION, ILLEGAL REQUEST, INVALID FIELD IN CDB.
> > >
> > >     >For example, if I have an *SBC-3* 1GByte target with a WSNZ of 0
> > >     and a MAXIMUM WRITE SAME LENGTH of 131072 blocks
> > >
> > >     > (64Mbytes with a sector size of 512), then I issue a WRITE SAME
> with
> > NUMBER OF LOGICAL BLOCKS of 0 and a
> > >
> > >     > LOGICAL BLOCK ADDRESS of 0 is it legal for the SBC-3 target to
> produce an
> > error because the computed number of
> > >
> > >     > blocks to be written will be greater than 131072?
> > >
> > >     That is not only "legal", it is also the behavior required by the
> > >     standard.
> > >
> > >     I believe the standard is unambiguous as written, but I'd support
> > >     an editorial clarification to reduce the degree of careful reading
> > >     required to reach that conclusion.
> > >
> > >
> > > The minor clarifications (where you added the word "computed" in
> > > brackets) were helpful and I'd say it would be helpful in the spec.
> > > Whatever happens thanks for clearing up the only acceptable behaviour!
> > >
> > > --
> > > Sitsofe | http://sucs.org/~sits/ <http://sucs.org/%7Esits/>
> > >
> > >
> > > _______________________________________________
> > > T10 mailing list
> > > T10 at t10.org
> > > http://www.t10.org/mailman/listinfo/t10
> >
> > _______________________________________________
> > T10 mailing list
> > T10 at t10.org
> > http://www.t10.org/mailman/listinfo/t10
>
> _______________________________________________
> T10 mailing list
> T10 at t10.org
> http://www.t10.org/mailman/listinfo/t10
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20160523/b3eb00e3/attachment.html>


More information about the T10 mailing list