Windows 95 VCACHE Disk Read and Write Architecture

Windows 95 introduced VCACHE, a 32-bit protected-mode driver that replaced the legacy real-mode SMARTDrive disk-caching utility to drastically improve storage performance. Integrated directly with the Installable File System (IFS) Manager, VCACHE provided a centralized, dynamic caching pool that scaled automatically based on available physical memory and system demand. This article explains the internal mechanics of VCACHE, detailing the complete path that disk read and write requests took through Windows 95's 32-bit storage stack.

Architectural Placement

VCACHE operated in ring 0 as a Virtual Device Driver (VCACHE.VXD). It was positioned between the Installable File System (IFS) Manager, file system drivers (such as VFAT.VXD), and the Block Input/Output Subsystem (IOS.VXD).

Unlike older caching software that reserved a fixed block of conventional or extended memory at boot, VCACHE allocated and released 4 KB memory pages dynamically from the system’s linear address space. It maintained a global hash table mapping volume identifiers and sector ranges to cached memory blocks, using a Least Recently Used (LRU) algorithm to govern buffer retention.

Processing Read Requests

When an application initiated a read operation via Win32 or MS-DOS APIs, VCACHE resolved the request using the following sequence:

  1. Request Dispatch: The system passed the read request to the IFS Manager, which routed it to the corresponding file system driver (typically VFAT).
  2. Cache Lookup: The file system driver translated logical file offsets into physical disk sectors and queried VCACHE's hash table to determine if those sectors already resided in memory.
  3. Cache Hit: If the requested sectors were present in VCACHE, the data was copied directly from the 32-bit cache buffer into the calling application's memory space, bypassing the physical disk entirely and completing the operation with minimal CPU overhead.
  4. Cache Miss: If any requested sectors were absent, VCACHE allocated empty or recycled 4 KB cache blocks.
  5. Physical Fetch: VCACHE invoked the Block I/O Subsystem (IOS.VXD), which routed the request down through the type-specific driver layers (such as DISKD.VXD) to the vendor-specific miniport or port driver (such as ESDI_506.PDR).
  6. Buffer Population: The storage hardware transferred the data into the allocated VCACHE buffers via Direct Memory Access (DMA) or Programmed I/O (PIO). VCACHE then copied the data to the user buffer and updated its LRU chain to mark those blocks as recently accessed.

Processing Write Requests

Windows 95 utilized VCACHE to support asynchronous "write-behind" (lazy write) caching, separating the application's perceived write completion from the physical commit to magnetic media:

  1. Intercept and Buffer: When a write request arrived from the IFS Manager, VCACHE determined whether the target sectors existed in the cache. If not, buffers were allocated. The incoming data was written directly into these 4 KB cache pages.
  2. Dirty Tagging: VCACHE flagged the modified cache blocks as "dirty," indicating that the contents in memory were newer than the data on the physical drive.
  3. Immediate Acknowledgment: In default write-behind mode, VCACHE returned a success status to the file system driver and calling application immediately after filling the cache buffer, allowing software execution to continue without waiting for the physical drive heads to move.
  4. Lazy Flush: A low-priority background thread periodically scanned VCACHE for dirty blocks. After a predetermined idle interval (typically between 1 to 4 seconds) or when dirty blocks reached a specific threshold, the thread gathered contiguous sectors into a single batch.
  5. Disk Commit: VCACHE handed the consolidated batch of dirty sectors to the I/O Subsystem, which executed the physical write to disk. Once the hardware signaled completion, VCACHE cleared the "dirty" flag from the corresponding memory blocks, returning them to a clean state eligible for reuse.
  6. Synchronous Overrides: If an application requested an explicit flush, called CommitFile, closed a critical file handle, or invoked a direct disk-write API, VCACHE bypassed the lazy-write queue and forced an immediate, synchronous flush through the hardware drivers before returning control to the caller.