What volume files are not cached by default?

[insertrealname]

I'm thinking of trying Fancy.cache for Volumes on the C: (boot) volume of my Windows 7 X64 notebook, initially just as a read cache (it is beta software, after all!). But whatever the specific configuration: am I right in thinking that the page-file (pagefile.sys, and other special system files) won't be cached by the Fancy.Cache, even though the system may use filesystem block reads/writes for these files?

[horizon]

I think I was already asking this... These files will afaik normally be cached...
The question of pagefile makes a good usecase for having pagefile on another volume. (Or turning the pagefile off completely... if you have got enough memory and no program that would be screaming "if page files is disabled"... like photoshop used to )
Imho the worst case is that cache will be filled with the paging.(Does not matter if we discuss read or write scenario.) Fro my POV it completely kills the whole idea of caching...

On nthe other hand, having the other files cached is great! (Whether it is data, userprofile, system dlls, applications, anything...)

I fully agree with your approach. The feature you will want to have disabled is actually deferred-writing. It implies the potential data-loss. Should some fatal failure prevent FC to perform delayed disk writes.
The current version itself (0.3.0.0) didn't cause any problems and the rest of my system is quite stable as well so I am already running with deferred writes enabled.

--Lukas

[insertrealname]

Thanks for your useful answer!

I should have been more explicit in what special files I'm thinking of, that probably should not be cached for system stability reasons: for instance, the backup programs I use create Volume Shadow Copies (via the VSS service, which creates system hidden files in the hidden folder "<VolumeRoot>\System Volume Information"), as does the Windows System Restore feature which I keep enabled as well.

And, of course, writes to the page files and hibernation file should not be cached either.

Anyway, I've fully backed-up my notebook system and have installed the disk version of Fancy.cache: 2GB read/write cache, 30secs write deferral, 64KB block size. I'll see if there are any performance benefits or problems over the next month or two. (A Windows Vista/7 sidebar gadget to continuously display actual used cache, hit rate, total reads, outstanding deferred writes, and total completed deferred writes, would be a great thing--no need to develop performance counters, just put all the existing collected information in a read-only shared memory area or something similar.)

[magic-man]

As far as the VSS backup files, here is what I have seen so far by MY observations:
If you use the DISK version, it appears that pretty much everything is cached, INCLUDING the backup files... It seems more like a block level cache. When you run a backup, the cache hit rate goes down.
If you use the VOLUME version, then VSS has no impact on the cache hit rate at all. So, I am thinking that VSS is like its own volume to the software (and the system).

As far as the debate over whether to cache the page file or not, we have to remember that at no time is the whole page file read or written to by the OS... It is done in blocks, so it will have minimal effect on the cache.

I have been running the DISK version, but am now switching back to the VOLUME version for more optimal caching (since my system does a daily backup to spinner).... There is one caveat to using the VOLUME version, though..... If you are making a VSS backup from a cached volume to another cached volume, the backup will have issues for some reason. This has already been pointed out to tech support for this version.

[horizon]

The prerequisity for FC is having system rock stable. At the same time the stability of FC mechanism is absolute must. In the end we talk about the potential data loss.

For my personal usage "FC for DISKs" is way more suitable than "FC for volumes". (Partitioned HDD; C: for system, F: for data.... want to have cached both at once with low costs. )

In terms of pagefile... It really depends on conditions but as a rule of thumb I believe we can say "If you *need* pagefile, then you have ram shortage." )
For example on my laptop I've got it completely disabled.
On most of my servers I've got it enabled just to be sure.
On the other servers, it is being used systematically and heavily. This occurs because of hungry applications. But I'd still prefere to have the pagefile disabled. Normally system tells you that you are out of virtual memory. (=kill the leaking application, buy more ram or enable PF )

--Lukas

[insertrealname]

Lukas, thanks for the explanations. There is no memory deficit on my notebook (8GB), but I leave the pagefile active simply because Windows basically expects it to be there: even when the system has no reason to use it, bits and pieces of some kind of data are being written to it. Also, in the event of some kind of bluescreen, system dump information may also be written there. So there is little advantage in disabling it. And as Magic-man pointed out above, cached pagefile blocks are not likely to be a major part of the active cache--But I hasten to add, that I have not read "Windows Internals 5th Ed.", which explains all of this in great detail, it's on my reading list.

I recently switched over from Windows 7 X86 to X64 (Lenovo preload) when an online vendor had a DRAM sale I couldn't refuse. The Windows X86 hardware configuration of the Lenovo notebook I use allowed a max. 2.75GB usage of 4GB installed (video ram device space is the culprit), and I was beginning to touch the limit a few times in daily use; the hidden memory could be used by products such as the ramdisk and cache software romexsoftware sells, but then you get into all kinds of hairy details about what happens to that memory in use, when the notebook is hibernated, etc.--much easier to simply switch to an X64 version of the operating system!

I still have to do the disk partition shrink/division into a system and a data partition, though, which is why I chose to install the disk and not the volume version.

Also, I was assuming (perhaps wrongly), that the disk version intercepts things at a lower level than the volume version (magic-man above seems to confirm that idea), which, while increasing risks with beta software, means that the logic perhaps isn't quite so complex.--But I still wonder about how all the NTFS metadata gets handled in this cache scenario (visions of cross-linked and invalid on-disk allocation tables!).

I really wish the FC performance statistics were a separate program that could run continously, e.g. a simple tray-icon that displayed the cache-hit percentage. Then I could easily track if this software does deliver benefit--subjectively, it does, but imagination isn't a substitute for data...

[magic-man]

But I still wonder about how all the NTFS metadata gets handled in this cache scenario (visions of cross-linked and invalid on-disk allocation tables!).

Lets over-simplify what a cache stores... Think of it like a table in a spread-sheet with only 2 columns: Location (volume number if you like) and Data.
The table would look like the following until flushed to drive(s):
0, jaskjlsjflsajlsdjlaj
0, ligjoeiugeuiuj
1, iueuierper
0, iotfurueru
...
The order never changes, it is a first in first out buffer. When it is time to flush the cache, the software would send the controller the data in the order it recieved it, and the controller puts it where it goes. Remember: the software is simply between the OS and the controller in the IO stream.
At least that is the way I understand it from the books... and the caches I build into my software at work to keep network IO at a minimum...

[horizon]

I assume that we are still talking about deferred writes...

FIFO makes sense, however I could imagine following features:

1. "Discard queued block write that is replaced by another write of the same block." (Repeated rewrites of single block wouldn't be queued in the cache but discarded. Only the resulting block would be actually written to the disk.)
2. "Prioritize neighbor blocks": If caching mechanism plans to do the actual writing of blockX and there was cached write of blockY, which is very close to blockX, they should be written at once. (No matter what was the original position of blockY in the queue.) For SSDs this probably does not matter but for rotating disks, here should be some saving of random access writes... (Another question is the question of RAID configurations...)

Both of these assume an active work with cache. (=searching, sorting,...) Not just FIFO approach. The question is how expensive such operations are...

While thinking of this, I guess that this is actually probably already implemented using other technologies... like NCQ (http://en.wikipedia.org/wiki/Native_Command_Queuing)...
The question is if FC's queueing could either "replace" NCQ or if there could be some synergy when using FC and NQC at once. (Consider that NQC can queue just 32 IOs, while FC can queue thousands of IOs...)

--Lukas

[magic-man]

Most of what you are thinking of is already implimented in NCQ.... NCQ is independent of the OS being used, as opposed to a cache which is OS dependant. To impliment a similar algorythm to NCQ would totally negate the performance gains we are seeing with the cache. The more complicated things get, the slower they get. If a software cache starts making controller level decisions, it would make it a lot harder to find issues if the controller were failing or there was a bug in the software. Then we would get caught up in the old blame game.. Was the issue hardware or software?

On some SSDs, they use a propriatary algorythm to detect negated writes and not write them to the SSD memory, IF the opposing commands are recieved within a specific time (like command A(write) recieved before write timeout, counter command B(delete file A) recieved before write timeout), no write occurs. That is why I like the delayed writes.... The commands go to the drive all at once, allowing the controller to do what it does with opposing commands if implimented: cancel them out.

[horizon]

MM> There was no plan to interfere with NCQ.

I still believe that proper queuing. (Resp. deciding what should be when submitted from cache to disk) could be always beneficial. (At least as far as disk-internal-queue (=Several MBs? Several IOs?) is MUCH smaller than FC's queue. (=Hundreds MBs/Thousands IOs) ) This simply gives a lot of space for really big optimizations. When disks will have GBs of cache and native 5 min delayed writes, we'll probably not need FC

Keeping things simple definitely makes a sense.
If you talk about the speed it's rises questions... It depends how eventual slowness would be demonstrated. (Extreme CPU peaks? / System freezes? / Bigger write-delay? ...?) I'd be ok with somewhat extra CPU consumption. I'd be ok with bigger write delay. I wouldn't be ok with freezes
And what is faster. Having things sorted by RAM/CPU or passing this to controllers/disks and letting them to sort out?