Conceptual Questions

Every time you save a document, commit code, or write to a database, a file system orchestrates a complex dance of metadata updates, data writes, and consistency guarantees. The choice of file system architecture—journaling, copy-on-write, or log-structured—fundamentally affects performance, reliability, and recoverability.

Interviewers ask about file system comparisons to gauge your understanding of storage tradeoffs: How do different designs balance write amplification, crash consistency, performance, and complexity? Answering well demonstrates systems thinking that separates strong candidates from average ones.

This page equips you with deep, practical knowledge of file system design philosophies and their real-world implications.

To understand why different file system architectures exist, we must first understand the problem they solve: crash consistency.

The Core Problem

File system operations often require multiple disk writes that must appear atomic. Consider a simple file creation:

1. Allocate an inode (write to inode bitmap)
2. Initialize inode fields (write to inode table)
3. Add directory entry (write to directory block)
4. Write actual file data (write to data blocks)

If power fails mid-way, the file system can be left in an inconsistent state:

• Directory points to uninitialized inode (crash after step 3, before step 2)
• Inode marked allocated but not referenced (crash after step 1, before step 3)
• Data blocks written but inode doesn't point to them (data orphaned)

Why This Is Hard

Disks don't guarantee order: Even if software issues writes in order (1, 2, 3, 4), the disk's internal scheduling may reorder them for performance. Write 4 might complete before write 1.

Atomicity only at sector level: Disks guarantee atomic writes only for single sectors (512 bytes or 4KB). Multi-sector updates are not atomic.

Volatile write caches: Disks have RAM caches for performance. Data in the cache isn't safe until flushed to platters. Power loss loses cache contents.

Solutions to Crash Consistency

Three major approaches have emerged:

1. Journaling: Write a description of the change first; apply it later
2. Copy-on-write (COW): Never overwrite; always write to new locations
3. Log-structured: Treat the entire file system as a sequential log

Each solves crash consistency differently, with distinct performance characteristics and tradeoffs.

Journaling file systems solve crash consistency by maintaining a write-ahead log (journal) of pending changes. Changes are written to the journal first; only after the journal is safely on disk are the actual file system structures updated.

How Journaling Works

Before operation:

1. Write transaction description to journal (what will change)
2. Write all affected blocks to journal
3. Write commit record (transaction complete)

Transaction committed (journal is durable): 4. Write actual changes to their final locations ("checkpoint") 5. Mark journal transaction as freed

On crash:

• If before step 3: Transaction incomplete → ignore journal entries
• If after step 3: Transaction committed → replay changes from journal

Recovery is fast: scan the journal (small, fixed-size area), replay any committed transactions. No full filesystem scan needed.

Types of Journaling

Data Journaling (Full Journaling):

• Journal contains both metadata AND data blocks
• Maximum safety: all data protected
• Significant write amplification: every block written twice
• Used by: ext3/ext4 in data=journal mode

Ordered Journaling (Default for ext4):

• Journal contains only metadata
• Data blocks written to final location BEFORE metadata journal commit
• Ordering guarantee: crash → data either there or not, but metadata consistent
• Less write amplification, good safety

Writeback Journaling (Fastest, Least Safe):

• Journal contains only metadata
• Data blocks can be written anytime (before or after metadata)
• Risk: metadata says file has data, but data blocks contain garbage
• Used when performance matters most, data integrity risk tolerable

Major Journaling File Systems

ext4 (Linux default):

• Extents for large files (vs. indirect block pointers)
• Delayed allocation for better space efficiency
• Journal checksums for reliability
• Backward compatible with ext2/ext3

XFS (High-performance):

• B+ tree for everything (directories, free space, metadata)
• Excellent scalability for large files and filesystems
• Metadata-only journaling for performance
• Supports real-time I/O for media workloads

NTFS (Windows):

• Full journaling of all metadata operations
• Change journal for file change tracking
• Support for encryption, compression, quotas
• Maximum file system size: 16 EB

JFS (IBM):

• Designed for server reliability
• Extents and B+ trees throughout
• Low CPU overhead during journaling

Copy-on-write file systems solve crash consistency by never overwriting existing data. Modifications always write to new disk locations. The transition from old state to new state is a single atomic pointer update.

How Copy-on-Write Works

When modifying a file:

1. Write new data to free blocks (old data unchanged)
2. Create new metadata blocks pointing to new data
3. Create new parent metadata blocks pointing to new children
4. Repeat up to the root (tree of changes)
5. Atomically update the superblock/root pointer to the new tree

After step 5:

• Old tree is unreferenced but still on disk
• New tree is complete and consistent

If crash before step 5:

• Superblock still points to old (consistent) tree
• New blocks are orphaned (freed on recovery)

This is called transactional semantics—the file system is either in the old state or the new state, never in between.

Benefits of Copy-on-Write

1. Crash Consistency Without Journal

• No separate journal needed—consistency is inherent in the design
• Recovery is instant: check uberblock, done

2. Free Snapshots

• Since old data isn't overwritten, snapshots are just pointers to old trees
• Creating a snapshot = saving a root pointer
• No data copying; snapshots are instant

3. Built-in Checksumming

• COW file systems typically include checksums for all blocks
• Detects bit rot, silent corruption, and RAID issues
• Self-healing with redundancy: bad block detected → replaced from mirror

4. Atomic Operations

• Group of changes is all-or-nothing
• Enables transactional file system operations

5. Clone and Deduplication

• Clones are space-efficient (share unchanged blocks)
• Block-level deduplication naturally fits the COW model

COW Tradeoffs and Challenges

1. Write Amplification

• Modifying one byte triggers cascading writes up the tree
• Small random writes are expensive (multiple blocks per small change)
• Particularly problematic for databases with many small updates

2. Fragmentation

• Sequential file writes become scattered as COW allocates new blocks
• Read performance degrades over time as files fragment
• Defragmentation is possible but adds overhead

3. Metadata Overhead

• Tree structures with checksums are more expensive than simple block pointers
• More CPU required for checksum verification

4. Complexity

• More complex implementation than traditional file systems
• Tuning requires understanding of COW mechanics

Log-structured file systems (LFS) take a radical approach: treat the entire disk as a sequential log. All writes—data and metadata—are appended to the end of the log. Nothing is ever overwritten in place.

The Core Idea

Traditional file systems optimize for random I/O (seek to location, read/write). But:

• Seeks are slow (milliseconds for HDD)
• Sequential I/O is fast (100x-1000x faster than random on HDD)
• Memory caches reduce reads; writes still hit disk

LFS insight: Batch all writes into large sequential segments. Turn random writes into sequential writes.

How Log-Structured Works

1. Buffer writes in memory
2. When buffer full (or sync requested), write entire segment sequentially
3. Segment contains data blocks, inodes, inode map updates—everything
4. Update inode map to point to new inode locations
5. Keep superblock pointing to current inode map

On read:

• Consult inode map (in memory) to find current inode location
• Read inode, follow block pointers to data

On crash:

• Scan log from last known checkpoint
• Reconstruct inode map from log entries
• Very fast recovery

The Garbage Collection Challenge

As the log grows, old segments contain dead data (superseded by newer writes). Without cleaning, the disk fills up.

Garbage collection (cleaning):

1. Select segment with significant dead data
2. Copy live blocks from segment to new log position
3. Update inode map for moved blocks
4. Mark segment as free

Cost of cleaning:

• LFS pays for writes twice: once during GC, once during normal write
• Write amplification can be significant
• GC competes with normal I/O for bandwidth

Cleaning strategies:

• Clean segments with highest dead block ratio (cost-benefit)
• Clean when idle or asynchronously
• Avoid cleaning hot data (it will die soon anyway)

Why LFS Shines for Flash/SSDs

SSDs have characteristics that make LFS ideal:

• No seek penalty: Random reads are as fast as sequential
• Write asymmetry: Writes must erase blocks before writing (expensive)
• Wear leveling: Spreading writes evenly extends device life

LFS naturally provides:

• Sequential writes (efficient for SSD write patterns)
• Wear leveling (writes go to different locations over time)
• Minimal write amplification for new writes
• Plays well with SSD's internal garbage collection

Let's systematically compare the three architectural approaches across key dimensions:

When to Choose Each Approach

Choose Journaling (ext4, XFS, NTFS) when:

• Reliability is important but not extreme
• Predictable, well-understood performance needed
• Compatibility with existing tooling required
• General-purpose workloads (workstations, servers)
• HDD storage (journal handles reordering)

Choose Copy-on-Write (ZFS, Btrfs) when:

• Data integrity is paramount (checksums matter)
• Snapshots are needed for backups/rollback
• Built-in RAID/volume management desired
• Long-term storage (protect against bit rot)
• Willing to invest in RAM for caching/metadata

Choose Log-Structured (F2FS) when:

• Flash storage (SSDs, eMMC, SD cards)
• Mobile devices (Android: F2FS common)
• Write-heavy workloads with large writes
• Wear leveling and flash longevity matter

Hybrid approaches:

• Many systems use COW + log-structured elements
• ZFS: COW semantics, but optimized for various patterns
• Btrfs: COW with optional logging for performance

Let's examine specific file systems that exemplify each approach.

ext4: The Reliable Workhorse

ext4 (fourth extended filesystem) is the default Linux file system, representing mature journaling design:

Key features:

• Extents: Contiguous block ranges instead of individual block pointers (less metadata, better for large files)
• Delayed allocation: Don't allocate blocks until flush time (better allocation decisions)
• Journal checksumming: Detect corruption in journal entries
• Flexible block groups: Better online resizing

Journaling behavior:

Default: data=ordered (metadata journaled, data written first)
Mount options: data=journal, data=writeback
Journal size: typically 128MB (configurable)

Performance characteristics:

• Excellent for general workloads
• Good random I/O
• Limited by journal serialization for heavy metadata workloads
• Maximum file system size: 1 EB; maximum file size: 16 TB

ZFS: The Bulletproof System

ZFS (Zettabyte File System) combines file system and volume manager with extreme data integrity focus:

Key features:

• Copy-on-write everywhere: Data, metadata, uberblock
• 256-bit checksums: Every block verified on read
• RAID-Z: Software RAID without write hole
• ARC (Adaptive Replacement Cache): Sophisticated caching
• Deduplication: Block-level, inline or offline
• Snapshots and clones: Instant, space-efficient

Data integrity:

Every read: Checksum verified
Bad checksum + redundancy: Auto-heal from good copy
Scrub: Background verification of all data
Result: Silent data corruption detected and corrected

Performance considerations:

• High memory requirements (1GB per TB of storage recommended for base, more for dedup)
• Record size tuning critical for workload (default 128KB)
• L2ARC (SSD cache) for read-heavy workloads
• SLOG (ZIL device) for synchronous write performance

F2FS: The Flash Specialist

F2FS (Flash-Friendly File System) is designed specifically for NAND flash storage:

Key features:

• Log-structured design: All writes append to log
• Hot/cold data separation: Different logs for different access patterns
• Flash-aware GC: Minimize unnecessary erases
• Node address table: Enables efficient wandering tree updates
• Roll-forward recovery: Reconstruct recent state from log

Flash optimizations:

Random → Sequential: All writes become sequential appends
Wear leveling: Writes distributed across flash
FTL awareness: Works with (not against) flash translation layer
TRIM support: Helps SSD know about freed blocks

Usage:

• Android devices (Pixel, Samsung, etc.)
• Embedded systems with flash storage
• SSDs where write patterns matter
• Not recommended for HDD (random reads become expensive)

When asked "Compare different file system architectures" or "What are the tradeoffs between journaling and copy-on-write?", structure your answer to show systematic thinking.

The Framework

Sample Answer Snippet

"The three main approaches to file system crash consistency are journaling, copy-on-write, and log-structured. Journaling writes a transaction log before updating in-place—on crash, we replay the log. ext4 does this. Copy-on-write never overwrites existing data; it writes to new locations and atomically updates the root pointer. ZFS and Btrfs use this, which naturally enables snapshots and checksumming. Log-structured systems append all writes sequentially and garbage collect old data—F2FS does this for flash storage.

The tradeoffs: journaling is mature and well-understood but doesn't provide checksums or snapshots natively. COW gives great integrity but can fragment and has higher write amplification. Log-structured is excellent for flash write patterns but requires careful garbage collection.

For a general Linux server, I'd recommend ext4. For data integrity and snapshots, ZFS. For flash/mobile devices, F2FS."

File system architecture represents fundamental engineering tradeoffs. Let's consolidate the key insights:

What's Next:

Having explored file system architectures, we'll conclude this module with the final essential conceptual topic: Security Concepts. Understanding authentication, authorization, access control models, and common attack vectors rounds out the operating systems knowledge expected in technical interviews.