Buffered writes hide errors in a way reads never do
Reading and writing are less symmetric than you (probably) think
Reading and writing look like mirror-image I/O operations, but buffering breaks the symmetry. A failed read surfaces its error before fread returns, so you never see bad data. A buffered write returns success immediately, while the real write, and any error, is deferred until the buffer flushes or the file closes. Most programmers check fwrite's return code but forget fflush, fclose, and fsync, so they never learn whether their data actually reached storage.
Buffered writing delays making the actual write system call; that's kind of the point. But it implies that error reporting is delayed too!
- Pannoniae
Great article :D The rabbithole actually goes even deeper because buffering on the read side is almost always good, but reads are often way more latency-sensitive than writes. Which leads to the paradox that increasing the buffer size / prefetching more with mmapping can lead to worse performance due to the added latency. And decreasing the buffer size can have the same effect due to issuing more calls, so in order to squeeze in the optimal throughput/latency ratio on reads you have to tune it per workload.... or just try a few different buffer sizes and see which one works better.
Writes are the opposite, they're usually not RAW (read-after-write), they're "fire and forget", so you don't really care about latency, but you do care a whole a lot about your writes actually arriving... again two competing parameters because the more you batch the writes, the faster they are but the bigger chance of a torn write or data loss. And unlike reads, writes are not idempotent on the application level so ideally you'd want some logic to atomically write a meaningful amount of data so it won't get torn, even if it crashes.
Now in practice just about no one actually does any of this but it's a fun thought :D
- 1317
oh i thought this would be about language and how the brain works, that article sounds more interesting to be honest sorry
- vatsachak
This is true even at the CPU cache level so it's probably going to trickle down all the way.
For example Jon G gave a talk at Jane Street about how he had a mysterious performance bug that was later attributed to cores fighting over the same cache line