I was hesitant on this initially. But I decided to give it a try because my old 8250 has only 768MB ram. This has put life back in the system now. I can’t believe that a good disk cache could make so much difference.

I haven’t had any issues with 3.0 beta so far.

Now some questions:

1. Is it possible to extend this concept to block level access rather than file level access?

2. many files don’t seem to be cached. Is there a specific rule that it uses to filter file access?

3. Can I train the filter to allow putting specific files (along with specific apps like it does now) in the cache (I have 4GB cache and I want it to use it fully, not 13%)?

4. It creates a 4GB file (I told it to use it all) on the 4GB flash drive formatted with fat32, and uses that as the store for cache (I think you have internal organization of cached files within that native file). Now, wouldn’t that create a fragmented file on the native fat32 FS? I know fragmentation is not a big issue with flash media because of low access times but its a scalability issue. 1 random access of 0.5ms vs. 10 random accesses of 0.5ms. It does add up. So, for optimal performance we would want to avoid any fragmentation on the native FS. OK, where is the question, you may ask….:-) The question is why does eboostr not use the native FS itself for storing cached files. Alternatively, why does eboostr not use the device as a raw device to format it in its internal format, store its files and not rely on the native FS at all? I know you may have done this to allow for part of the device to used for something else e.g. a user can store his photos on the same drive as well as eboostr cache. But is the raw device a possibility in the future?

I will bother you if I hit a beta issue. So far, it looks darn good!