OSNews

"Managing a flash cache is tricky because you not only need to worry about evicting least-recently-used filesystem pages, but you also want to bypass the cache during sequential I/O and evict pages that are usually accessed sequentially. I wonder if they even bother implementing these considerations. "

Of course they bypass the cache for sequential I/O. Perhaps not in the spun-down case, but how likely is it that you're going to be doing significant multi-block sequential I/O while expecting your disk to remain spun down?

The Robson/ReadyDrive Flash Cache is supposed to have two components: a write cache to keep the drive spun down (something's always writing to the drive in Windows... probaby logs no one ever looks at or NTFS MetaData... who knows?). There's also a read-cache that stores what would normally go into the paging file and some pages of executable code. This is the kind of data that is NOT generally accessed in long sequential reads, but instead more or less random small reads.

Sure, the memory page caching algorithms in widespread use can do a good job of keeping relevant pages around for program code, but this only works based on short term behavior of programs. The whole point of Windows SuperFetch, which is the underlying cache policy engine for these systems, is to find long term trends in page usage and to prewarm the cache with pages that the shorter-term algorithms have no way of knowing about. Given this level of long-term paging, the flash cache makes sense as a location that doesn't cost as much as main memory to store random-access code pages. Is Flash ideal to replace memory or HDDs? No! Ready* is just a matter of using a technology that's widely extant for a task it's well-suited to.

Windows NT has of course had disk caching since the original 3.1 version of NT. The memory manager and filesystem drivers both interact with the Cache Manager (Cc* subsystem) and have done so for ages. It's all pretty heavily tied in with the VM system, so there's pretty much a unified cache for both memory pages and disk file pages. Files are mapped in 256 KB FIFO views, but when a page falls out of a view, it isn't evicted from memory immediately... instead it's put on a standby list whence it can be retrieved quickly through a "soft" page-fault.

I think you should reconsider your notions that Windows is not as advanced as Linux on the Kernel level. It doesn't seem to move as quickly as Linux does in terms of new user-visible features, but that's largely because the kernel is hidden away and you don't have this nice /proc filesystem to see detailed data in. Instead, you have to go look through not-so-well-documented performance counters. You also can't see the source code and you don't pick and choose which features you want while compiling it. It is also the case that Linux does move faster into more niches than NT does because anyone can take it and adapt it to their needs. Microsoft only spends efforts on optimizing NT in areas and for machines where it makes business sense for them to do so.