I/O buffering
A buffer is a waiting area. Think of a coat-check counter: people arrive at all sorts of speeds, but the counter holds coats in between so the cloakroom attendant and the guests do not have to be in lockstep. I/O buffering is the OS keeping a chunk of memory — a buffer — between a fast party and a slow one, so that data can pile up or drain at its own pace and neither side has to wait on the other's exact rhythm.
Concretely, buffering solves several distinct problems. First, speed mismatch: a program may produce data far faster (or slower) than a device can take it; a buffer absorbs the difference so the producer is not throttled to the device's pace. Second, transfer-size mismatch: a disk likes to be written a whole block at a time, but a program may write a few bytes at a time; the OS gathers those small writes in a buffer and flushes a full block at once. Third, it lets the data stay put during a transfer: when a network packet arrives in fragments, a buffer assembles the whole message before handing it up. A simple write therefore often does not go straight to the device — it copies your bytes into a kernel buffer and returns, and the actual device write happens later.
Why it matters: buffering is one of the quiet workhorses that makes I/O efficient and programs simple — you can write one byte at a time without paying a full disk operation each time. But it has an honest cost and a honest danger. The cost is the extra copy and the memory used. The danger is that buffered data is not yet safely on the device: if power fails after write returns but before the buffer is flushed, that data is lost — which is why programs that need durability must explicitly force the buffer out (fsync) rather than trust that a returned write means written-to-disk.
Your program writes a log line of 40 bytes a thousand times. Instead of a thousand disk operations, the OS collects them in a buffer and writes the disk in a few full 4 KB blocks — vastly faster, but the last lines may be lost if power fails before the buffer is flushed.
A buffer absorbs speed and size mismatches; the trade-off is data not yet on the device.
Buffering and caching are not the same: a buffer is a staging area for data in transit, while a cache keeps copies of data likely to be reused. A returned write only means the data reached a buffer, not the disk.