SMARTDRV Disk Caching and Buffers in MS-DOS 6.22

This article explains how MS-DOS 6.22 uses the SMARTDrive utility (SMARTDRV.EXE) to optimize disk I/O performance through dynamic read and write memory buffers. By intercepting low-level disk interrupts, SMARTDRV caches frequently accessed data in extended (XMS) or expanded (EMS) memory. The following sections break down how read caching, write-behind caching, buffer management, and data flushing operate under MS-DOS 6.22.

The Role of SMARTDRV in MS-DOS 6.22

In MS-DOS 6.22, SMARTDRV is typically loaded as a Terminate-and-Stay-Resident (TSR) program via AUTOEXEC.BAT (or as a device driver via CONFIG.SYS). Its primary goal is to minimize slow physical access to hard drives and floppy disks by staging data in faster system RAM.

SMARTDRV hooks INT 13h (BIOS disk services) and INT 21h (DOS API services). When software requests data from a storage medium, SMARTDRV intercepts the request before it reaches the hardware controller.

Read Buffering (Read Caching)

Read caching relies on the principle of locality of reference. When an application requests data from a disk:

  1. Cache Interception: SMARTDRV checks its read buffers in memory to see if the requested sectors already reside in RAM.
  2. Cache Hit: If the data is present, SMARTDRV copies it directly from the cache to the application’s memory buffer, bypassing the physical disk entirely.
  3. Cache Miss and Read-Ahead: If the data is not in memory, SMARTDRV reads the requested sectors from the physical drive along with additional adjacent sectors (read-ahead prefetching). These sectors are loaded into the read buffer, anticipating that the application will request sequential data next.

SMARTDRV manages its read buffer pool using a Least Recently Used (LRU) replacement policy. When buffers are full, older, unaccessed data blocks are discarded to make room for new sectors.

Write Buffering (Write-Behind Caching)

Write caching, also known as deferred or write-behind caching, speeds up write operations by decoupling application execution from mechanical drive latency.

  1. Staging Writes: When a program writes data to a disk, SMARTDRV intercepts the write call, places the data into designated write buffers in RAM, and immediately returns a success status to the application.
  2. Asynchronous Flushing: The physical writing of the cached data is deferred until CPU and bus idle time, or until a specific flush condition is met.
  3. Write Consolidation: By delaying writes, SMARTDRV can organize sectors into sequential blocks, reducing hard disk read/write head movement (track seeking). Redundant writes to the same sector are overwritten in the buffer rather than committed repeatedly to disk.

Data Integrity and Safe Flushing in Version 6.22

Earlier versions of SMARTDRV (such as the version in MS-DOS 6.0) suffered from potential data corruption if a user rebooted or powered down while write buffers were still unwritten. MS-DOS 6.22 resolved this with several safeguards:

  • Synchronous Command Prompt Flushing: SMARTDRV automatically commits all dirty write buffers to disk before returning to the command prompt (C:\>).
  • Reboot Interception: Pressing Ctrl+Alt+Del triggers SMARTDRV to flush all pending write operations to disk before the system reboots.
  • Manual Flushing: Users and batch files can force an immediate cache flush by executing SMARTDRV /C.
  • Removable Media Defaults: By default, write caching is disabled on floppy drives to prevent data loss if a disk is ejected prematurely. Read caching remains enabled for those drives unless explicitly disabled.

Buffer Configuration and Memory Usage

SMARTDRV configuration is controlled via command-line switches:

SMARTDRV [drive[+|-]] [InitCacheSize] [WinCacheSize]
  • Drive Flags: Specifying a drive letter alone (e.g., C) enables read caching and write caching. Adding a plus sign (C+) explicitly enables both. Specifying a minus sign (C-) disables caching for that drive entirely. Passing a drive letter with only read caching enabled is accomplished by omitting the write parameter during setup.
  • InitCacheSize: Defines the size of the cache buffer in kilobytes when running under pure MS-DOS.
  • WinCacheSize: Defines the smaller buffer size that SMARTDRV dynamically shrinks to when Microsoft Windows 3.1x launches, yielding RAM back to the operating environment.

SMARTDRV requires HIMEM.SYS to be loaded first, as its cache buffers are allocated out of extended memory, keeping conventional memory overhead low.