Disk drives are slow.
I mean, they're faster now, especially with the advent of Solid State Drives, but they're
still slower than volatile RAM.
Rewind to the 90s and we find that RAM responds in tens of nanoseconds, whilst disk response
times are in the tens of milliseconds.
Six orders of magnitude difference.
A disk cache then, seeks to use the speed advantage of memory to bolster effective disk
speeds.
By the mid 90s, most drives incorporated at least 64K of cache on their controller boards,
but even then this could be supplemented with interface cards carrying their own cache storage.
But we also get something known as Page Cache.
This is an area of main system RAM used by the Operating System to also speed up disk
access times.
This is often why the term "Buffer" is used to describe the disk cache, retaining the
distinction.
Page cache is often reused multiple times, whilst data in the disk buffer is often used
only briefly, and often consists of pre-fetched data, rather than data already in use.
The three assumptions disk cache routines are built upon are;
1.
When you read or write something on disk, chances are you'll read it again soon.
This is the "principle of locality".
Once you start working in an area, you tend to stay in that area.
For example, under DOS, part of COMMAND.COM gets re-read after you exit any large program.
This is why you often get a flash of disk activity after exiting a DOS application.
2.
Another aspect of the principle of locality is that when you read one sector, you usually
end up reading the next sector shortly afterwards.
This implies that when we fire up the disk to read sector X, we might as well read X+1,
X+2 and so on.
It's the seek time which takes the lion's share of the disk read time, and so those
additional un-read sectors get placed in the buffer, ready for retrieval.
3.
Whenever you tell a program to read in a file, and you make changes, you'll soon after tell
the system to re-write the file.
Even though you haven't changed that much of the file, DOS will attempt to re-write
the whole shebang anyway.
A cache can therefore check a sector to be written against a sector which currently exists
on disk, and if there's no change, skips that part of the rewrite.
DOS versions after 4.01 came with a disk caching program called SMARTDRV, which could be loaded
in the startup routine.
Windows '95 then brought in a program called VCACHE, which did exactly the same thing.
So why had buffers on disk at all?
Why not let the Operating System deal with everything?
Well the disk buffer can handle the principle of locality dealing with sectors much quicker
than the Operating System, and although disk buffers are small, and usually much less than
0.1% of the entire disk volume, it allows enough space to accommodate several tracks
of data and makes one to one interleaving possible.
Data can be fed to the buffer, the system can pull data from the buffer, giving the
disk heads enough time to locate the next block, and so on.
With mechanical drives, the volume is so great, increasing the buffer space doesn't have a
drastic effect, as it tends to deal with only the immediate concern.
In fact, if you kept increasing the buffer size, you'd end up with the next step in hard
drives...
Solid State Drives.
Although these themselves, usually still have a volatile buffer of DRAM, as it's faster
than persistent memory.
So I guess all that's left to say is, cache me outside, how bow dah?