The CONFIG.SYS BUFFERS statement appeared with MS-DOS 2, which amongst other big changes added fixed disk support. It also made two changes to the way that DOS handled IO:
- The file allocation table (FAT) was no-longer always held in memory, instead being treated like any other sector; and
- Instead of a single DOS disk sector buffer, the BUFFERS CONFIG.SYS statement enabled the user to select between 1 and 99 sector buffers.
Since previously (in DOS 1.x) the FAT had been held entirely in memory, no disk IO was needed to find the sectors being requested by open file IO. But with DOS 2, this could need serveral IOs – Tim Paterson, an original architect of MS-DOS, published a superb article describing the details in Byte Magazine in 1983, now available here (and cached here).
But why does this matter?
In testing old disks with my simple DiskTest utility, I couldn’t help but notice a wealth of full-stroke IO going on, especially with the 40MB WD-384R since it’s stepper is so vocal. The reason is clear: with FAT-16 (DOS 4), the FAT is over 80KB (a list of 40,000 clusters each 16-bits wide), and with each buffer being 512-bytes, there simply isn’t enough buffer space for the FAT. So, as the random IO test runs then buffers containing FAT data will be victimised by file data on its way through, and hence DOS needs to seek back to the FAT.
This lead to what is approaching full-stoke IO in this case as the drive happened to be nearly full when I ran the test, so the majority (or all) of the test file was near the opposite end of the drive to the FAT.
Tuning
But this leads to a tuning opportunity for the PC/XT disk system, particularly for random IO applications such as databases.
Dividing the drive(s) into smaller partitions doesn’t really help, since DOS selects a cluster size so that the FAT (on a FAT-16 volume) tends to be between 64 and 128KB – so with 99 buffers available (49.5KB), the FAT will never completely fit in the buffer space. And in any case, with a maximum of only 640KB available on the PC/XT, there simply isn’t much space for a disk cache (each buffer consumes 528 bytes of RAM).
Here’s the difference that buffers makes to the WD-384R under DOS 4 with a single 40MB FAT-16 partition:
For random IO, the system is performing at over five times the rate with 99 buffers, than with a single buffer, and 40% better than with 16 buffers.
For a PC/XT, with its ST-406 drive, DOS 2, and a single 10MB FAT-12 partition, the impacts of buffers is rather different – as the FAT is only about 4KB, so it can fit comfortably in just 8 buffers:
This all leads me to a few conclusions:
- For FAT-16, use 99 buffers, unless the memory is really needed by programs
- if space permits (up to 16MB), use a FAT-12 partition for database files since less buffers are needed for optimum performance
- on later (AT) machines with even a little XMS, a disk caching utility such as SmartDrv should offer significant further gains