Preload currently accessed files -> improve Audio/Video/Film

[Axel Mertes]

Hi Romex Support Team,

I just stumbled this morning over the PrimoCache statistics.
Apparently most - if not all - of my L2 cache is free'ed up after running a defragmentation on the cache drive over night.
The defrag moved around roughly over 1.5 TByte of data during last night.
Before the defragmentation process there were only 32 KByte left on each L1 and L2 cache, so a lot of read operations would have come directly from the ~2 TByte SSD cache instead of the HDD RAID. However, after the defragmentation process (first since a week, though...) almost the complete L2 cache was noted to be free.

Obviously that means a lot = most of the L2 cache blocks have been invalidated during the nightly operation. This is logic if the cache blocks are moved to other places and their original content is being overwritten, but not immediately re-read again (which is normal in defragmentation). My cache now needs to fill up again by reading from HDD.

In that context I once more want to remind you to implement a feature that whenever we write to a disk, we should be able to carbon copy the written blocks to the L2 "read" cache immediately. That would leave my cache filled until the last block (once it was transacting enough data) and safe pretty much future HDD read operations.


One important note in that context:
As due to the fact that I regularly defragment the volumes, the data in the defragmented files MUST be mostly the fresh data, written to HDD since the last defragmentation process. This is true due to the fact that all other files are already defragmented on the disk and will likely not be moved by the defrag software. So only fresh data is moved around - exactly the data that is already in the read cache. I see that by the speed of the defragmentation, running at up to 800 MByte/s to 2 GByte/s I/O speeds (measured using Sysinternals Process Explorer). So if during defragmentation moved around blocks would be immediately carbon copied to the L2 cache, then my cache in total would stay pretty much the same, just that the blocks on disk have been re-arranged for faster stream reading.


I know I have iterated on this subject before, but I still see a BIG use for this.

The same rules for automatic read-ahead caching with selectable number of blocks, to accelerate streaming file playback. I do defragment the drives regularly and that results in a read-ahead cache running on steroids if implemented.

[Support]

In that context I once more want to remind you to implement a feature that whenever we write to a disk, we should be able to carbon copy the written blocks to the L2 "read" cache immediately. That would leave my cache filled until the last block (once it was transacting enough data) and safe pretty much future HDD read operations.

Thank you! We have started to handle the defragment issues and optimizations.

[Axel Mertes]

Thats great news! Thanks for the reply.

Now I can't wait to put it "in action". If you want me to beta test this beforehand, please contact me via axel point magnamana point com.