VERIFY & how the data got into the cache

Ralph Weber Ralph.Weber at wdc.com
Mon Sep 30 08:33:42 PDT 2013


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

Unless I misheard them, WD engineers beg to differ with the following
comments in the "4.15 specs for read operation" thread:
<<begin quote>>
For each LBA accessed by a read operation that is a verify operation, the
device server shall perform a read cache operation only if:
a) the logical block data in the cache for that LBA is the result of a read
medium operation; and
b) no subsequent write operation has been processed for that LBA.
RE: It doesn’t matter how the cache got the data.  If there is more recent
data in the cache, all verify operations need to force that data to media
before performing the verify medium operation.
<<end quote>>
How the data got into the cache very much matters (or so my experts tell me).
For this reason, WD engineering sees the current 4.15 requirements as being
fixated on the wrong thing.
VERIFY commands are required to use data that is read from the medium. If the
cache contains data that is newer then:
  1.  that data must be written to the medium,
  2.  the cache must be invalidated, and
  3.  the data must be read from the medium (and stored in cache if so
desired).
Any specification that says otherwise is misleading the reader.
It is not acceptable to write the newer cache data to the medium and then use
the cache contents without first reading the medium, unless the goal of the
letter ballot changes is to negate the first sentence in the SBC-2 definition
of VERIFY ... to whit:
"The VERIFY (10) command (see table 53) requests that the device server
verify the specified logical block(s) on the medium."
Furthermore, the "newer data in cache" issue should be covered by b) in the
WD proposed wording.
All the best,
.Ralph



More information about the T10 mailing list