The Hidden Asymmetries Between I/O Read and Write

Read and write system calls appear structurally parallel but exhibit fundamental behavioral differences rooted in buffering. Block storage devices operate on fixed-size units—512 bytes, 2k, or 4k depending on hardware—requiring the kernel to maintain a buffer cache that translates arbitrary byte-aligned requests into block-aligned operations. User-space libraries add additional buffering, typically 4096 or 8192 bytes, to reduce system call overhead, which costs hundreds of clock cycles per invocation.

The asymmetry emerges in error handling and timing. Read operations complete the entire path from storage to the application buffer before returning; any errors encountered are reported immediately. Write operations return success immediately after copying data to the user-space buffer, deferring the actual system call until the buffer fills or is explicitly flushed via fflush, fseek, or fclose. This deferred execution means errors may not surface until well after the original write call completes.

The article raises whether programmers check return codes for these operations, particularly fflush and close. Skipping such checks risks missing write errors, since the kernel only guarantees data reached its buffer cache, not physical storage. On POSIX systems with network filesystems like NFS or SMB/CIFS, write errors can be reported only during file close, creating another failure point for code that does not validate close return values. Even on local filesystems, data may remain in kernel buffers for seconds before reaching the actual storage device.