a log-structured file system
Imagine keeping a diary where you never go back to erase or rewrite an old page — you only ever append to the end. To update yesterday's entry you simply write a fresh note at the bottom saying what changed, and the latest note always wins. A log-structured file system treats the whole disk like that diary: it never modifies data in place; instead it buffers up changes and writes them all out sequentially as one big append to the end of a single, ever-growing log.
The motivation is performance on disks where seeks are expensive. Scattered small writes force the disk head to jump all over the place; a log-structured file system collects many pending writes — new data blocks, changed inodes, directory updates — in memory, then streams them out in one long sequential write to the log, which a disk does very fast. Because inodes also move when rewritten, the system keeps an inode map that records where the current version of each inode now lives, and that map is itself written into the log and tracked from a fixed checkpoint region. Reads can still be fast since the inode map points straight to the latest copy. Over time, of course, the log fills the disk and is littered with old, superseded versions, so a background cleaner (a garbage collector) scans old log segments, copies the few still-live blocks forward into new writes, and frees the reclaimed segments for reuse.
The big win is that writes become almost purely sequential, which historically beat seek-bound write performance dramatically and gives natural crash consistency (the tail of the log is just the most recent state). The honest costs are read fragmentation (a file's blocks can end up scattered across the log over many updates) and the cleaner itself, which competes for disk bandwidth and can stall things when the disk is nearly full. Pure log-structured file systems are rarer on general-purpose disks today, but the core idea is everywhere: it is essentially how flash-based SSDs and their flash translation layers work internally, since flash also forbids overwriting in place.
Saving small edits to ten files: instead of ten scattered in-place writes (ten seeks), an LFS gathers all ten files' new blocks plus their updated inodes into one segment and writes it as a single sequential pass at the end of the log. Later, a cleaner reclaims the now-dead old versions those files left behind.
Turn many scattered writes into one big sequential append; a background cleaner later reclaims dead space.
The idea lives on inside SSDs: flash cannot overwrite in place either, so the flash translation layer writes new data elsewhere and garbage-collects old blocks — log-structured thinking at the device level.