LBACACHE on FreeDOS: Sector Caching Without Gambling with Writes

LBACACHE is a FreeDOS disk read cache for 386-class or newer systems with XMS memory. It intercepts BIOS disk access, retains recently read sectors in extended memory, and serves repeated reads without returning to slow physical media. It supports LBA and CHS access, hard disks, and optional floppy caching.

Its most important safety property is easy to miss: LBACACHE does not defer writes. Even when it updates or allocates a cached copy during a write, the actual write still proceeds to the underlying BIOS device. That makes it a read cache, not a write-back cache.

Load a conservative cache

With no options, LBACACHE autodetects cacheable hard disks and uses its default buffer size. An explicit size larger than two digits is interpreted in kilobytes.

LBACACHE 2048
LBACACHE STAT

The cache needs XMS, so load an appropriate XMS provider before it. The resident program still consumes some conventional or upper memory for hooks and bookkeeping. Compare MEM /C before and after loading, especially on a game-oriented configuration where every kilobyte below 640 KB matters.

Autodetection is preferable to a manual DRV list. The list names BIOS physical drives, not DOS letters: BIOS drive 80h may contain several partitions. An incorrect manual assumption can leave the intended disk uncached or attach policy to the wrong device order after a BIOS change.

Measure the workload instead of maximizing size

Use LBACACHE STAT to view understandable cache statistics and LBACACHE ZERO to reset counters before a test.

LBACACHE ZERO
REM Run the application or copy workload here.
LBACACHE STAT

A large allocation is not automatically faster. XMS used for cache is unavailable to DPMI applications, RAM disks, archives, and games. If the working set is smaller than the cache, additional megabytes may produce no extra hits. Measure cold and warm runs and include total task time, not only the reported hit percentage.

The TUNA option makes lookup fully associative. It may increase hits, but searching the whole cache can cost more CPU than the extra hits save. The documentation specifically presents it as a tradeoff to test, not a universal tuning flag.

Understand what happens on writes

If a sector already exists in cache, LBACACHE updates its cached copy when the underlying write occurs so a later read does not return stale data. TUNW goes further by allocating cache space for newly written sectors in anticipation of a reread. It still does not postpone the disk write.

This distinction prevents one class of power-loss corruption, but it does not make every stack coherent. A program or driver that bypasses BIOS INT 13h may modify storage without LBACACHE seeing it. Disk swapping, removable media, geometry changes, and another cache installed in the wrong order can also invalidate assumptions.

Use LBACACHE SYNC when media or lower-level access changes. For LBACACHE, sync forgets cached data rather than writing dirty sectors because it has no delayed writes. The command uses BIOS eject notifications for cacheable drives, so test it before combining it with BIOS-driven optical or removable devices.

Treat floppy caching as a separate experiment

FLOP enables caching for detected floppy drives. Floppy media is removable and geometry varies, so stale identity or wrong geometry is more dangerous than on a fixed disk. The official help warns that a geometry mistake can corrupt copied data or the disk itself.

If floppy performance matters, begin with known 1.44 MB media in a matching drive, label each test disk, and use checksums before and after removal. Never swap disks while cached state is assumed valid. A modest speed gain is not worth uncertainty about which medium supplied a sector.

Place the TSR deliberately

LBACACHE can be loaded from CONFIG.SYS with INSTALL, from AUTOEXEC.BAT, or interactively. TSR ordering matters because several programs can hook the same BIOS interrupt chain. Keep it near the storage utilities it depends on, and document which component was loaded before and after it.

LBACACHE STOP attempts to restore the interrupt chain and frees XMS. If another resident program hooked the chain later, a complete unload may not be possible; a small stub can remain. Only the last compatible instance is likely to unload cleanly. Do not repeatedly load and stop caches in a production boot without checking resident state.

A useful startup design has two menu entries: one with a measured LBACACHE configuration and one without any disk cache. That gives old software and recovery tools a clean BIOS path when troubleshooting.

Prove both performance and coherence

A cache benchmark needs a cold path, a warm path, and a data-integrity check. Start from the cache-free boot profile, checksum the test files, and time one complete workload. Reboot into the LBACACHE profile, reset its counters with ZERO, run the workload once, record STAT, and run it again without changing the inputs. The second cached pass should improve the operation that actually matters, not just report a high hit ratio.

Then exercise invalidation. Modify a test file through the normal DOS path, run SYNC, and confirm that a new read and checksum see the new bytes. Repeat the test after any tool that accesses the disk below DOS or through its own protected-mode driver. If LBACACHE cannot observe that path, do not combine the two in the same boot profile.

Measure memory pressure at the same time. Record free conventional memory, free XMS, application startup success, and task duration for several cache sizes. A 16 MB cache that saves one second but prevents a DPMI program from allocating memory is a regression. Choose the smallest allocation after which the warm-run improvement flattens.

Finally, test the recovery profile with the cache completely absent. Disk repair, imaging, partitioning, and geometry-sensitive tools should run there so their view is not filtered through a resident INT 13h hook. Keeping benchmark and recovery configurations separate makes performance reproducible and eliminates the temptation to diagnose storage damage through the component being tested.

LBACACHE should make repeated reads faster while leaving write completion to the disk. Verify that model on the actual BIOS, memory manager, drive, and TSR order, then choose the smallest cache that materially improves the workload.

Related:

Sources: