What is a Log-Structured File System?
Learn how log-structured file systems turn random writes into sequential appends, and why cleaning and flash suitability matter.
Expected Interview Answer
A log-structured file system treats the entire disk as a single sequential append-only log, buffering all writes — data and metadata alike — into large segments that are written out in one continuous stream rather than updating scattered blocks in place.
Instead of overwriting a file’s existing blocks, a log-structured file system (LFS) always appends new versions of data and their updated inode information to the end of the log, turning many small random writes into one large sequential write, which suits spinning disks and flash equally well since sequential writes avoid seek overhead and align well with flash erase blocks. Because old versions of data are left behind as the log grows, a background cleaner (garbage collector) periodically scans older segments, identifies blocks that are still live versus superseded, and compacts live data into fresh segments to reclaim space occupied by dead versions. Locating the current version of any file goes through an inode map that is itself checkpointed into the log, so reads still resolve in roughly constant time despite data living wherever it was last appended. The tradeoff is that cleaning overhead grows under heavy random-write and near-full-disk workloads, and this same append-only, garbage-collected design is the direct ancestor of modern flash translation layers and copy-on-write file systems.
- Converts scattered random writes into one fast sequential stream
- Naturally suits flash storage, which favors sequential writes and erase-block alignment
- Simplifies crash recovery since the log itself records a consistent history
- Underpins modern flash translation layers and copy-on-write designs
AI Mentor Explanation
A log-structured file system is like a ball-by-ball commentary log where every delivery is written as a new entry at the end of the scorebook rather than erasing and rewriting a scoreboard cell for each change. Old entries about a batter’s earlier score are simply superseded by later entries, not erased, so a separate index has to be consulted to find each player’s current tally quickly. Periodically, a statistician goes back through old overs to discard superseded entries and compact the scorebook, exactly like the cleaner reclaiming space from stale log segments.
Step-by-Step Explanation
Step 1
Buffer writes
Incoming writes, both data and updated inodes, are collected in memory into a segment.
Step 2
Append sequentially
The full segment is written to the end of the log in one large sequential I/O, avoiding scattered in-place writes.
Step 3
Update the inode map
A checkpointed inode map is updated to point to the new location of each modified file’s data.
Step 4
Clean stale segments
A background cleaner scans older segments, compacts live blocks into fresh segments, and reclaims space from superseded versions.
What Interviewer Expects
- Understanding of append-only, sequential writes as the core design
- Awareness of the cleaner/garbage collector role and its overhead
- Knowledge of how reads are still located efficiently via an inode map
- Ability to connect LFS concepts to flash translation layers and copy-on-write file systems
Common Mistakes
- Thinking LFS never reclaims space and grows forever
- Believing reads become slow because data is scattered across the log
- Not knowing that cleaning overhead is the main downside under heavy writes
- Confusing log-structured file systems with journaling file systems (a journal supplements in-place updates; LFS replaces them)
Best Answer (HR Friendly)
“A log-structured file system never edits data in place — instead it always writes new changes to the end of a continuous log, which turns lots of small scattered writes into one fast sequential write. Because old versions pile up behind the current ones, a background cleanup process regularly reclaims that wasted space. It is a great fit for flash storage and is part of the design lineage behind modern SSD controllers and copy-on-write file systems.”
Code Example
struct inode_map_entry {
int inode_num;
off_t log_offset; /* current location of this inode’s data in the log */
};
off_t append_to_log(void *data, size_t len, off_t *log_tail) {
off_t write_offset = *log_tail;
write_at(write_offset, data, len); /* sequential append, never in place */
*log_tail += len;
return write_offset;
}
void write_file_block(int inode_num, void *block, size_t len,
off_t *log_tail, struct inode_map_entry *imap) {
off_t new_offset = append_to_log(block, len, log_tail);
imap[inode_num].log_offset = new_offset; /* old block is now stale */
}Follow-up Questions
- How does the LFS cleaner decide which blocks in a segment are still live?
- Why do log-structured designs suit flash storage particularly well?
- How does crash recovery work in a log-structured file system?
- What is the relationship between LFS and copy-on-write file systems like ZFS or Btrfs?
MCQ Practice
1. What is the core write strategy of a log-structured file system?
LFS batches writes into segments and always appends them sequentially, converting random writes into one large sequential write.
2. What is the main overhead introduced by a log-structured design?
Because old versions are left behind as the log grows, a cleaner must periodically compact segments to reclaim space, which is the main cost of LFS.
3. How does LFS still find the current version of a file quickly?
An inode map, itself checkpointed into the log, tracks where each file’s current data lives, keeping reads efficient despite append-only writes.
Flash Cards
What is a log-structured file system? — A file system that treats disk writes as an append-only sequential log instead of updating blocks in place.
Why does LFS turn random writes into sequential writes? — Because it buffers changes into segments and always appends them to the end of the log.
What is the LFS cleaner? — A background process that compacts live data out of old segments and reclaims space from superseded versions.
Why does LFS suit flash storage? — Sequential writes avoid random-write penalties and align well with flash erase-block behavior.