SBC-3 r35j 4.15 text 'xxx medium operation that is not part of an xxx operation' leaves too much to the imagination

Gerry Houlder gerry.houlder at seagate.com
Wed Oct 2 09:10:44 PDT 2013


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

i agree with Ralph that that all write medium operations are part of a
write operation; there is no concept of a write medium operation that is
not tied to a write operation. i don't buy the WRITE AND VERIFY command
example, this has always been thought of as a write operation followed by a
verify operation. Even special cases like FORMAT and SANITIZE OVERWRITE are
expected to be write operations.
The case is murkier for read medium operations -- there are things like
speculative read ahead that can't be tied to the scope of any existing read
command. This brings up the question of whether a cache manager or other
background task manager can issue "read operations" or whether it issues
"read medium operations". If they issue read operations, then we can
probably say that there are no read medium operations that are not part of
read operations.
On Mon, Sep 30, 2013 at 10:40 AM, Elliott, Robert (Server Storage) <
Elliott at hp.com> wrote:
>  ** **
>
> ** **
>
> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Ralph
> Weber
> *Sent:* Friday, 27 September, 2013 4:17 PM
> *To:* t10 at t10.org
> *Subject:* SBC-3 r35j 4.15 text 'xxx medium operation that is not part of
> an xxx operation' leaves too much to the imagination****
>
> ** **
>
> While some of those present thought the intent was somehow related to
> specifying the proper operation of cache coherency implementations, Western
> Digital reviewers found the following two list introductions
> incomprehensibly vague in SBC-3 r35j.****
>
>    - For each LBA accessed by a write medium operation that is not part
>    of a write operation:****
>    - For each LBA accessed by a read medium operation that is not part of
>    a read operation:****
>
> Is this intended to reach into the design of background operations?
>
> Proposing a solution based on the current, quicksand text seems like a
> dubious endeavor, at best.
>
> If the intent is to specify who a device server maintains cache coherency,
> the majority of Western Digital reviewers question the need for such
> untestable requirements in a T10 standard. If some other concern underlies
> the existing text, then perhaps the addition of an e.g. immediately prior
> to the colon will set the proper tone.****
>
> ** **
>
> ** **
>
> The intent is to be clear that every read medium operation must get data
> from the cache if more recent data is there, and every write medium
> operation must keep the cache up to date.****
>
> ** **
>
> It’s a catch-all for commands like WRITE AND VERIFY and other model
> material that refers directly to medium operations but doesn’t mention the
> cache impacts:****
>
>		  Page 195****
>
> The WRITE AND VERIFY (10) command (see table 111) requests that the device
> server:****
>
> 1) transfer the specified the logical block data for the command from the
> Data-Out Buffer;****
>
> 2) perform write medium operations to the specified LBAs;****
>
> 3) perform verify operations from the specified LBAs; and****
>
> 4) if specified, perform a compare operation on:****
>
>		  A) the logical block data transferred from the Data-Out
> Buffer; and****
>
>		  B) the logical block data from the verify operations.…****
>
> ** **
>
> Maybe WRITE AND VERIFY should just be described as performing a write
> operation, because the verify operation includes the write medium operation
> if needed.****
>
> ** **
>
>
> One fear is clear. If nothing is done, over jealous test engineers are
> likely to extend their vision of the cache to include the sector write
> buffer that is part of the hardware that actually records data on the
> medium.
>
> Warning: This comment is the result of a very preliminary review by
> Western Digital engineers. The Western Digital review of SBC-3 r35j is
> ongoing, and more issues seem likely to be unearthed. Due to the gravity of
> this issue Western Digital concluded that prompt disclosure would best
> serve the interests of T10 and the industry.
>
> All the best,
>
> .Ralph****
>



More information about the T10 mailing list