read-ahead

When you start reading a file from the beginning and keep going, the computer can make a good guess: you will probably want the next chunk too. Rather than wait for you to ask for each piece and fetch it one slow disk trip at a time, the kernel reads ahead - it fetches the upcoming part of the file into the page cache before you request it, so by the time you ask, the data is already in RAM. That speculative pre-fetching of file data you have not asked for yet is read-ahead.

The kernel watches your access pattern. If your reads look sequential - offset 0, then 4 KiB, then 8 KiB - it concludes you are streaming through the file and starts pulling in larger windows ahead of your current position, growing the read-ahead window as the sequential streak continues (often up to a cap like 128 KiB). It also overlaps this with your processing: while you chew on the bytes already delivered, the next window is being fetched in the background, hiding disk latency behind useful work. If instead your reads jump around randomly, the kernel detects that the prediction is not paying off and shrinks or disables read-ahead so it does not waste bandwidth and cache on pages you will not touch. You can also give explicit hints with posix_fadvise() (POSIX_FADV_SEQUENTIAL to read ahead aggressively, POSIX_FADV_RANDOM to turn it off) or madvise() on a mapping.

Why it matters: read-ahead is a big part of why streaming a large file, copying it, or scanning a database sequentially achieves near-disk-bandwidth throughput instead of crawling at one request's latency per block. The honest caveats: it is a heuristic and can guess wrong - aggressive read-ahead on a truly random workload pollutes the cache with pages you never use and wastes I/O bandwidth, which is why telling the kernel POSIX_FADV_RANDOM for random access can actually speed things up.