What is the internal logic of Microsoft ReadyBoost?
Even a theoretical answer will do.
migrated from stackoverflow.com Jul 26 '10 at 12:11
This question came from our site for professional and enthusiast programmers.
ReadyBoost consists of a service (%SystemRoot%\System32\Emdmgmt.dll) that runs in a Service Host process and a volume filter driver (%SystemRoot%\System32\Drivers\Ecache.sys). (Emd is short for External Memory Device, the working name for ReadyBoost during its development.) When you insert a flash device like a USB key into a system, the ReadyBoost service looks at the device to determine its performance characteristics and stores the results of its test in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Emdmgmt.
If your flash device is fast enough and you agree, the service creates a caching file named Ready Boost.sfcache in the root of the device, which it will use to store cached pages (the initial cache is built by querying SuperFetch’s cache, but later contents are fully managed by ReadyBoost independently).
After the ReadyBoost service initializes caching, the Ecache.sys device driver intercepts all reads and writes to local hard disk volumes and copies any data being read or written into the caching file that the service created, with certain exceptions such as data that hasn’t been read in a long while, or data that belongs to Volume Snapshot requests. Ecache.sys compresses data and typically achieves a 2:1 compression ratio, so a 4-GB cache file will usually contain 8 GB of data. The driver encrypts each block it writes using AES encryption with a randomly generated per-boot session key in order to guarantee the privacy of the data in the cache if the device is removed from the system.
When ReadyBoost sees random reads that can be satisfied from the cache, it services them from there, but because hard disks have better sequential read access than flash memory, it lets reads that are part of sequential access patterns go directly to the disk even if the data is in the cache. Likewise, when reading the cache, if large I/Os have to be done, the on-disk cache will be read instead.
This comes from the Windows Internals Book, it has been made shorter to fit as an answer.