In post #222 Ao1 chose a good scenario/example that can help illustrate some of the dynamics involved with the operation of the "system file cache" mechanism within the Windows OS:
Quote Originally Posted by Ao1 View Post
To better understand the three monitoring levels I thought a “simple” file copy would help elaborate what happens where and when. ...

E drive is static data only. The Test File is 731,082,752 bytes.

The copy/ delete/ copy process was done as follows:
• Copy file (right click) Test.avi from E:\Test File to E:\ (paste)
• Move copied file to recycle bin (right click, delete)
• Re paste file to E:\ (right click paste)

The above was carried out within a minute, but interesting it would appear that reads and writes generated by the file transfer occurred sometime later on the actual device, but back to that later.

I like the diagram from the TechNet article as it shows the flow of data. If I use that diagram to try and understand what is happening from the monitoring results below:

All uncoloured entries are activities occurring between stages 1 and 5.
The TechNet diagram that Ao1 mentions (and which is also included within his post) basically reflects the case where the data to be accessed by a file read I/O operation is not presently located within the system file cache and so must first be retrieved from the actual storage media (i.e., the physical disk device).

This case/diagram is the second scenario/diagram shown amongst the three diagrams that Ao1 included within his prior post #203, where the first TechNet diagram is the case in which the data to be transferred by the file read I/O operation is present within the system file cache (i.e., a "system file cache read hit") and the third TechNet diagram is the case where the data written to the system file cache is subsequently (at some later time) written/transferred out to the actual storage media.

It is important to note that the file "copy / delete /copy" example chosen by Ao1 actually involves all three of these TechNet cases/diagrams and not simply the second diagram alone/only. This can be substantiated by the summary I/O operation performance metrics that were collected by hIOmon and which are included/shown within Ao1's post.

For example, the "system file cache read hit" I/O operation count can be derived by subtracting the hIOmon "ReadSystemCacheIOPmissCount" metric value from its associated "ReadSystemCacheIOPcount" metric value. The hIOmon "ReadDataXferSystemCacheHit" metric value shows the corresponding amount of data transferred from the system file cache for the "system file cache read hit" I/O operations. In any case, these metrics reflect those read I/O operations that fall into the TechNet diagram/scenario number one.

Similarly, the hIOmon "ReadSystemCacheIOPmissCount" and the "ReadDataXferSystemCacheMiss" metric values can be associated with the second TechNet diagram. In addition, the hIOmon "PhyDev Read Data Xfer" metric can generally be associated with the retrieval of the data from the actual physical device in the case of a "system file cache read miss" scenario (i.e., the second TechNet diagram).

Finally, the hIOmon "WriteSystemCacheIOPcount", the "WriteDataXferSystemCacheHit", and the "PhyDev Read Write Xfer" metrics can be associated with the third TechNet diagram (where the data associated with file write I/O operations performed as a result of the "file copy" actions are first written to the system file cache and then subsequently transferred to the actual storage media).

As an aside, unhiding the hIOmon "Read IOP Count" metric column within the displayed hIOmon metrics table might be helpful for the sake of completeness.

One other brief comment here. Folks will likely notice several occasions where there are multiple rows with the same file name and same time period within the displayed hIOmon metrics table. This is due to the "multiple opened instances" of the same file (as briefly described within my prior post #219).

I suspect that these multiple instances of the same file are related to processes such as Windows Explorer (e.g., performing the actual copy of the file), the System process (which can be involved with "pre-fetching" portions of the file into the system file cache and also with subsequently writing out the file from the system file cache to the storage media), and perhaps an Antivirus program (such as Microsoft Security Essentials) that are (concurrently) accessing the same file. Please note that the names of those specific processes involved with a particular instance of a file are included amongst the summary I/O operation metrics collected by hIOmon for the particular file instance.

This post is already getting a bit long, so I'll defer my other comments to another subsequent post.