Operating systems and concurrency
Files and storage
How file systems map names to inodes, how journaling and the page cache affect durability, and how the storage devices underneath behave, from SATA disks and SSDs to cloud volumes.
A file looks simple: a name, some bytes, and a write call that returns. Underneath, the operating system splits the work across several layers. A name points to an inode. Writes sit in memory in the page cache. A journal records changes, and the device stores them in its own way, with its own write rules and wear.
Most data-loss bugs happen in the gaps between these layers. A write returns, but the bytes are still in memory. A rename is durable, but the file it replaced was not. Knowing the layers tells you which call actually promises durability.
The big idea
Three layers decide what survives a crash:
- The file system maps names to inodes and keeps metadata consistent through a journal.
- The page cache holds file data in RAM. A plain
writeonly reaches this layer. - The device writes to flash or magnetic media, and it may cache writes too.
Durability requires an explicit flush through all three, using fsync, and that flush can fail in ways your code must handle.
Concepts in this topic
| Step | Concept | What it answers |
|---|---|---|
| 1 | File systems and journaling | How are names, inodes and metadata kept consistent? |
| 2 | Page cache and fsync | When is a write actually on disk? |
| 3 | Durable file writes | How do you update a file so a crash never leaves half of it? |
| 4 | Storage devices and SSDs | Why do random writes and wear matter? |
| 5 | Cloud storage and RAID | What do disks, volumes and object stores promise? |
Why this matters
Databases, message brokers and log systems all need durable writes, and their correctness depends on the file system layer. The write-ahead log assumes that a flushed record stays flushed. Object storage, covered in blob storage, makes different promises, and those differ from a local disk.
Which layer to suspect
When data is missing after a restart, check the layers in order. Did the application call fsync, or only write? Did it flush the directory after a create or rename? Does the device honor flushes, or does it hold a volatile write cache without protection? Did a RAID rebuild or a volume failover lose the only copy? Each question rules out one layer, and the first "no" usually points at the bug.
Common mistakes
- Treating a successful
writecall as durable. - Ignoring the result of
fsync, which can fail even when the write seemed to succeed. - Assuming a cloud volume has the same guarantees as a local disk, or as object storage.
Key takeaways
- A write returns when the data reaches the page cache, not the disk.
fsyncis the durability point, and its errors must be handled.- Devices add their own caches, wear and write amplification to the story.
Further learning
Next, see file systems and journaling for how names and inodes are organized.
Related
The memory hierarchy
From registers to SSDs to the network, the latency numbers that dominate performance, and why the tier your data sits in matters more than the code you write.
Storage engines: pages, B-trees and the WAL
How a relational database stores rows in fixed-size pages, finds them in a B+tree, caches them in a buffer pool, and survives crashes with a write-ahead log.
Write-ahead log
The write-ahead log records every change before the page is written. How commits become durable, how recovery replays the log, and what group commit and checkpoints do.
Object storage
Store files and media in S3-style object stores. Keep bytes out of your app servers and databases, and design uploads, metadata and costs around that split.