From: Jonathan de Boyne Pollard on
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote
cite="mid:21a20133-afbb-46ae-88ae-ae9f5069a8d5(a)15g2000yqi.googlegroups.com"
type="cite">
<p>The <code>FILE_FLAG_SEQUENTIAL_SCAN</code> flag seems to still
use the file system cache at least in my environment. </p>
</blockquote>
<p>Of course it does.&nbsp; Think about what the flag means.&nbsp; It's telling
the cache about the expected usage pattern of the file, so that the
cache can tailor its behaviour accordingly.&nbsp; It wouldn't make any sense
to have the flag without the cache.&nbsp; There's even a Microsoft
KnowledgeBase article, 98756, explaining the operation of the cache in
response to this flag, in detail.&nbsp; Note from the explanation that this
flag doesn't actually do what you want to do (which is to flush already
read data pages from the cache maps).<br>
</p>
</body>
</html>
From: Jonathan de Boyne Pollard on
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:OB$iPw0tKHA.732(a)TK2MSFTNGP06.phx.gbl" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<p>The <code>FILE_FLAG_SEQUENTIAL_SCAN</code> flag seems to
still use the file system cache at least in my environment.</p>
</blockquote>
<p>Of course it does. [...] There's even a Microsoft KnowledgeBase
article, 98756, explaining the operation of the cache in response to
this flag, in detail. Note from the explanation that this flag doesn't
actually do what you want to do (which is to flush already read data
pages from the cache maps).</p>
</blockquote>
<p>The [MSKB article] you mention does seem to imply that <code>FILE_FLAG_SEQUENTIAL_SCAN</code>
caches forward, only.</p>
<p>How else do you read "dispenses with keeping a history of reads"?</p>
</blockquote>
<p>One reads it <em>properly</em>.&nbsp; Dispensing with the history of
reads means that the cache manager doesn't do what it normally does,
which is attempt to auto-detect sequential read behaviour by comparing
the current read request to prior requests, to see whether they are
(roughly) sequential.&nbsp; It dispenses with keeping that <em>history of
reads</em>.&nbsp; This is because, of course, it doesn't need it.&nbsp; It's
already been told explicitly what it would otherwise auto-detect.&nbsp; Once
again, note that this doesn't actually do what is wanted, and indeed is
nothing to do with what is wanted, which isn't to do with any saved
history of read requests, but is to do with the read data pages and the
cache maps.<br>
</p>
</body>
</html>
From: Jonathan de Boyne Pollard on
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:O3oUiR3tKHA.4568(a)TK2MSFTNGP05.phx.gbl" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<p wrap="">The <code>FILE_FLAG_SEQUENTIAL_SCAN</code> flag
seems to still use the file system cache at least in my environment.<br>
</p>
</blockquote>
<p wrap="">Of course it does. [...] There's even a Microsoft
KnowledgeBase article, 98756, explaining the operation of the cache in
response to this flag, in detail. Note from the explanation that this
flag doesn't actually do what you want to do (which is to flush already
read data pages from the cache maps).<br>
</p>
</blockquote>
<p wrap="">The [MSKB article] you mention does seem to imply that
<code>FILE_FLAG_SEQUENTIAL_SCAN</code> caches forward, only.<br>
<br>
How else do you read "dispenses with keeping a history of reads"?<br>
</p>
</blockquote>
<p wrap="">One reads it <em>properly</em>. Dispensing with the
history of reads means that the cache manager doesn't do what it
normally does, which is attempt to auto-detect sequential read
behaviour by comparing the current read request to prior requests, to
see whether they are (roughly) sequential. It dispenses with keeping
that <em>history of reads</em>. This is because, of course, it doesn't
need it. It's already been told explicitly what it would otherwise
auto-detect. Once again, note that this doesn't actually do what is
wanted, and indeed is nothing to do with what is wanted, which isn't to
do with any saved history of read requests, but is to do with the read
data pages and the cache maps.<br>
</p>
</blockquote>
<p wrap="">My reading of that MS KB paragraph is more along the line
of "the look-ahead cache is filled-in whenever the file pointer moves,
and the cached data is discarded as soon as it is actually
requested/read by the client application". If you have some
authoritative source to support your quite different interpretation of
the same sentence, please provide a pointer to such documentation.<br>
</p>
</blockquote>
<p>Your reading is wrong; and it doesn't take much knowledge of how
mechanisms such as auto-detecting sequential read behaviour work to
figure this out from first principles.&nbsp; There are only so many ways to
implement such a mechanism.&nbsp; (This makes it most amusing that Compaq
Computer Corporation in 1998, some years after the creation of Windows
NT and OS/2, both of which have sequential I/O pattern detection and
API flags for processes to specify intended access patterns, filed a
U.S. patent claiming to have invented a method for detecting sequential
read patterns by keeping a history of read requests in a table.) You
can even figure it out from looking at the parameters to the <code>CcReadAhead()</code>
function.&nbsp; You can also read plenty of documentation on the internals
of the cache manager in Windows NT that tells you this, including
Rajeev Nagar's book.&nbsp; And this documentation tells you, as does the
MSKB article, that the <code>FO_SEQUENTIAL_ONLY</code> flag controls
read-ahead, not free-behind.<br>
</p>
</body>
</html>