hIOmon SSD Performance Monitor - Understanding desktop usage patterns.

[Ao1]

Hi Overthere. You have the patience of a saint. I can see that some of the items I’m now looking at were covered in much earlier posts, but I did not twig on to what you were saying, it went right over my head.

Let me see if I can test your patience further

To better understand the three monitoring levels I thought a “simple” file copy would help elaborate what happens where and when.

I’ve noticed that if you right click to copy a file, then delete the copied file and then immediately recopy it, the transfer appears to be instantaneous.

This scenario would therefore seem to give me a way of tracking what happens in the file system and what actually happens on the disk and when.

To do this I selected:
• 1 (Device and file I/O Performance Analysis).
• E:\*
• 1 (Enable collection of Physical Device Extended Metrics)

Any which way it‘s going to be covered.

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.

Assumptions:
• Performance in these stages is down to the OS and RAM. Nothing is occurring on the device.
• The system cache IOP miss counts are page faults from RAM, which then require a re-read from the file system.
• Most of the Read/ Write FastIOPcounts are done in cache and when this happens there are independent of the device speed. If I look at the results from post #48 it is likely that the 87.6% FastIOPcounts with HDD were predominantly achieved by cache. The SSD managed 100% because the speed of the SSD was such that it could satisfy non cached read IOP counts in less than a millisecond. [Edit] So it seems activities from 1 to 5 are designed to mitigate the slow speed impact of a HDD. I wonder if the file system driver/ cache manager could be better optimised for SSD. (?)

\Device\HarddiskVolume3 is when data actually gets read and written to the device. I assume stage 7 - Disk Driver.

Assumptions:
• This is when the speed of the device counts, however when this actually occurs is typically “after the event”. The speed of the device only therefor counts if it is a direct read/ write that bypasses the cache manager. (Assuming no further load when the read/ write occurs)

E: is a summary of all activity within stages 1 and 7

Assumptions:
• This is showing all activity be it in cache or on the device.

\Device\HarddiskVolume3:\<DASD>\VMMFrom previous posts this has been explained as “system flags associated with the I/O operation indicate involvement by the system “Virtual Memory Manager (VMM)”.

Assumptions:
• Entry 21 is why the re-paste appeared to be instantaneous. It was copying data from the VMM to the file system driver. The actual read/ write on the device occurred a minute later.

I’ve attached the script, which contains hidden cells (that can be un-hidden if required) that are not shown on the image below. I only wanted to show relevant data to what I try to describe above, but if I missed anything it can be un-hidden.

Please feel free to wade into mistakes in my understanding and I will correct the post accordingly.