File Cache Management

Other versions of this page are also available for the following:
Windows Mobile Not SupportedWindows Embedded CE Supported

The file system cache manager provides a stream-based file cache that tracks cached data on a per-file basis. Unlike a block-level disk cache, which tracks disk blocks with no record of which files the blocks belong to, a stream-based cache includes information about the file, the block sizes used by the volume, and file access patterns. This enables the cache to do the following:

  • Read file data in increments that are optimal for the volume.
  • Pre-load file data in anticipation of future accesses.
  • Remove data from the cache when it is not likely to be used again.

The file system cache manager ensures that the most important file data is available in RAM. Because the data can be accessed directly in RAM, the cache minimizes file retrieval time and improves file system performance. In addition, because the cache minimizes disk I/O, caching reduces power usage.

The file cache provides additional advantages that contribute to overall efficiency. For example, the way the cache is implemented helps avoid data duplication between the file cache and memory-mapped files. If file data is paged into a memory-mapped file, it is not stored in the cache. This improves RAM usage and saves data copying performance.

The file cache manager can read multiple pages of file data into the cache at a time, based on an optimal paging size for the volume. In this way, file accesses occur in sizes that match the basic blocks in compressed ROM, providing potential performance gains.

The file system cache manager is implemented as a file system filter that is tightly integrated with the kernel memory-mapped file and paging infrastructure. Thus, if an application uses caching, the application interacts directly with a file system filter and with the memory-mapped file interface. The file system filter and memory-mapped file interface use a common caching layer in the kernel, which in turn communicates with a lower layer provided by the filter for performing uncached accesses to the underlying file system.

The following are some significant characteristics of the file cache manager:

  • Loadable on any file system volume
    Because the cache is implemented as a file system filter, it can be loaded on any file system without making any modifications to the file system driver. Caching properties, such as whether the cache is write-through or write-back, can be controlled on a per-volume basis.
  • Loadable at any level in the file system filter stack
    If other filters are loaded on a file system volume, the file system cache manager filter can be loaded above or below any of those filters.
    The file system cache manager filter cannot be loaded multiple times on a single volume. If a second instance of the filter is loaded on the filter stack, it detects lower instances of itself on the stack and avoid loading a second time.
  • Uses the file paging pool
    The file system cache and memory-mapped files share a common paging pool. The file paging pool is a single pool of RAM pages used for storing cached file data. The kernel uses a different and entirely independent paging pool for storing executable pages, the loader paging pool.
  • Supports many-to-one file access
    If multiple cached file handles are open, the handles are accessed as a single uncached handle in the filters and file system driver (FSD) below the cache. File system layers below the cache do not have any way to determine which of the cached file handles corresponds to an uncached access.
    The file system cache manager provides per-handle I/O atomicity, That is, if two callers try to simultaneously access a file using separate handles, the file system cache manager ensures that the accesses occur one at a time. The file cache filter checks for file sharing, access rights, and byte-range locking.
  • Not involved with metadata caching
    Because a file system filter has no interaction with the way the file system driver stores file system metadata, the file system cache manager does not cache metadata. File system drivers can use the disk cache to implement metadata caching. Metadata is information about the file that is separate from the file contents, such as the file name, timestamp(s), and attributes.
  • Not associated with the loader
    Unlike the cache manager from desktop versions of Windows, the Windows Embedded CE file system cache manager does not provide executable mappings to the loader. The loader creates executable mappings and manages paging executables into RAM by itself.
  • Insulated from file system programming interfaces
    The file system cache manager does not support callbacks to the file system API from filters and FSDs below it. To access file system layers below them, filters can use only the FILTERHOOK that is provided.
    Filters that call file APIs without going through the FILTERHOOK must be located above the file cache filter in the filter stack.
    A filter or FSD that is loaded below the cache filter must not call any file system API. A filter can call its FILTERHOOK, but nothing else. If the filter/FSD calls a file system API, even to access a different volume, it can cause a system deadlock. Any filter that calls file system APIs other than its FILTERHOOK must be loaded on the filter stack above the cache filter. Any FSD that calls file system APIs is unsafe for use with the file cache filter. Do not mount the file cache on such an FSD.

Community Additions