8. File Systems, Storage, and Persistent Data

Introduction and Context

A computer system is useful only when it can preserve information beyond the lifetime of a process or a power cycle. Main memory provides fast working space, but it is volatile: its contents normally disappear when power is removed. Persistent storage supplies continuity. It holds operating-system components, application programs, user documents, databases, configuration data, audit records, and recovery information.

The operating system presents persistent storage through abstractions that are easier to use than raw device addresses. A user typically works with files and directories rather than sectors, flash pages, or disk heads. Behind this apparent simplicity lies a substantial set of responsibilities: naming data, allocating space, enforcing protection, translating logical requests into device operations, exploiting locality, maintaining consistency, tolerating failures, and recovering after crashes.

This chapter examines file-system organization from the interface visible to applications through the mechanisms used on disks, solid-state drives, and storage arrays. Particular attention is given to allocation, free-space management, buffering, journaling, log-structured and copy-on-write designs, RAID, persistence and consistency, and the trade-offs that arise in real deployments.

Learning Objectives

After studying this chapter, a student should be able to:

• explain file and directory abstractions and distinguish logical from physical storage;
• compare contiguous, linked, indexed, and extent-based allocation;
• evaluate free-space, caching, buffering, and I/O scheduling techniques;
• describe journaling, log-structured, and copy-on-write file systems;
• analyze RAID levels and SSD-specific storage behavior;
• distinguish visibility, durability, ordering, and atomicity of updates;
• design recovery and protection strategies for realistic workloads;
• assess technical, organizational, and governance risks in persistent-data systems.

The File Abstraction and the Namespace

A file is a named, persistent sequence of bytes or, in some systems, a structured object with associated metadata. Common metadata includes a file type, size, owner, group, access permissions, timestamps, link count, and pointers to data blocks. The operating system normally exposes operations such as create, open, read, write, seek, truncate, close, rename, and delete. An open operation returns a file descriptor or handle through which later operations are performed.

The file abstraction separates a program from the physical location of its data. A program may request bytes at a logical offset without knowing whether those bytes reside on a rotating disk, an SSD, a remote block device, or a replicated volume. This indirection enables migration, caching, protection, and device replacement without changing application code.

Directories organize names into a namespace. A directory maps names to file-system objects, usually through a tree rooted at a designated root directory. Modern systems may also support hard links, symbolic links, mount points, and special files. A hard link adds another directory entry referring to the same underlying object; deleting one name does not necessarily delete the object while other links or open references remain. A symbolic link stores a path to another object and can therefore become dangling.

Path resolution converts a pathname into an object. Relative paths are interpreted with respect to a process's current working directory, whereas absolute paths begin at the root. During resolution, the operating system checks directory permissions, symbolic links, mount boundaries, and possible race conditions. Security-sensitive programs must avoid assuming that a pathname remains associated with the same object between checking and use.

File systems commonly distinguish the file's contents from its metadata. A write may modify data blocks, file size, modification time, allocation maps, and directory entries. Correct ordering among these updates is essential. For example, exposing a directory entry before its data and metadata are safely recorded can produce an object that exists after recovery but points to invalid or uninitialized space.

Allocation: Mapping Files to Storage

A file system must map a logical file offset to physical storage locations. The allocation method affects sequential performance, random access, fragmentation, metadata overhead, and recovery complexity.

Contiguous and Extent-Based Allocation

In contiguous allocation, a file occupies consecutive blocks. The mapping is simple: a starting block and a length identify the entire file. Sequential access is efficient, and random access is inexpensive. However, files that grow may require relocation, and free space can become externally fragmented.

Extent-based allocation provides a practical compromise. A file is represented by one or more extents, each describing a starting block and a length. Small files may need only one extent, while growing or fragmented files acquire additional extents. Extents reduce metadata overhead compared with block-by-block pointers and are particularly effective for large sequential files. They do not eliminate fragmentation, but allocation policies can attempt to place related extents near one another.

Linked Allocation

Linked allocation stores a pointer to the next block in each allocated block. A file can grow without requiring contiguous space, and external fragmentation is reduced. Sequential access is natural, but random access is slow because the chain may have to be followed from its beginning. A damaged pointer can also make a large portion of a file inaccessible.

A file-allocation table places the links in a separate table rather than inside data blocks. This improves access to the chain but creates a potentially large metadata structure that must itself be protected and cached.

Indexed Allocation and Inodes

Indexed allocation stores pointers to data blocks in an index block. Large files can use multi-level indexing: an inode or file-control structure points to direct blocks, single-indirect blocks, double-indirect blocks, or extent trees. This arrangement supports random access while allowing small files to avoid excessive metadata overhead. The inode model used by many Unix-like systems stores attributes and block-location information in a persistent object separate from the directory entry.

No allocation method is universally best. Sequential media favor locality and large transfers; databases may require predictable random access; virtual-machine images benefit from extents and sparse-file support; and flash storage changes the cost model because overwriting a logical block may require internal erase and garbage-collection work.

Free-Space Management and Locality

The system must record which storage units are free. Bitmaps represent one bit per block or allocation unit and make it relatively easy to find runs of free space. Free lists link free units together and can be simple, but finding a sufficiently large contiguous region may be expensive. Grouping, counting, extent trees, and space maps improve performance on large volumes.

Allocation policies attempt to preserve locality. Blocks belonging to a file may be placed near one another; directories and frequently accessed metadata may be positioned strategically; and related files may be allocated within the same block group or allocation group. Locality reduces seek and rotational delay on hard disks and can also reduce translation and garbage-collection overhead on flash devices.

Fragmentation has two forms. External fragmentation means free space is divided into small separated regions. Internal fragmentation occurs when an allocated unit is larger than the data it contains. Large blocks improve transfer efficiency but waste more space for small files. Extents, delayed allocation, online defragmentation, and workload-aware placement are common responses.

Sparse files represent large logical regions of zeros without allocating physical blocks for them. They are valuable for virtual disks and scientific data structures, but applications must understand that logical size and physical space consumption are different quantities.

The Storage-I/O Path: Caching, Buffering, and Ordering

A read or write travels through several layers: the application, system-call interface, file system, page or buffer cache, block layer, device driver, controller, and storage medium. Each layer may reorder, combine, split, delay, or cache requests. The resulting performance and correctness depend on the interaction among layers rather than on the file system alone.

The page cache keeps recently used file data in memory. A cache hit avoids device access; sequential-read detection may trigger read-ahead; and dirty pages may be written later by background workers. Buffering often absorbs differences between producer and consumer speeds. Write-back caching improves throughput, whereas write-through or synchronous modes provide stronger durability at greater latency.

Caching creates an important distinction between a successful write system call and persistent storage. A write may be accepted into memory or a device's volatile cache without having reached non-volatile media. An application that requires durability must use an appropriate synchronization operation, such as a file or range flush, and the storage stack must honor its ordering and persistence guarantees. Directory updates may require separate synchronization from file contents.

Direct I/O can reduce page-cache duplication and is sometimes used by databases that implement their own caching. It does not automatically make writes durable or eliminate alignment constraints. Memory mapping offers a different interface but still requires explicit consideration of dirty-page write-back and synchronization.

On hard disks, request scheduling historically sought to reduce seek and rotational delay through algorithms such as elevator-style ordering. SSDs have little mechanical positioning cost and support internal parallelism, so queue depth, locality, flash translation, garbage collection, and write amplification become more important. Nevertheless, operating-system scheduling remains relevant because it controls fairness, batching, and pressure on device queues.

Consistency, Atomicity, and Persistence

Three properties are often confused. Visibility concerns when another process can observe an update. Atomicity concerns whether an operation appears complete or not at all. Durability concerns whether the update survives a specified failure, such as process termination, kernel crash, sudden power loss, or device destruction. A system may provide one property without providing the others.

A rename within one file system is often designed as an atomic namespace operation. Applications exploit this by writing a new temporary file, synchronizing it, and atomically renaming it over the old version. The method is useful for configuration files, but its correctness depends on synchronizing the relevant data and directory metadata and on understanding the platform's guarantees.

Ordering is equally important. Suppose a file-system implementation records a directory entry before recording the inode and data block it references. A crash between these events can leave a directory entry pointing to invalid content. Conversely, writing metadata before data may expose stale or uninitialized data. File systems therefore impose dependencies, use barriers or flushes, or employ transactional techniques.

Distributed or network file systems add another dimension. Client caches, leases, server failover, and network partitions can produce semantics different from those of a local file system. Engineers must specify whether they require close-to-open consistency, session consistency, linearizable metadata operations, or merely eventual convergence.

Journaling and Crash Recovery

A crash can interrupt a multi-step update. Journaling records intended metadata or data changes in a log before applying them to their normal locations. During recovery, committed log records are replayed and incomplete transactions are discarded or ignored. The journal is therefore a mechanism for restoring file-system invariants, not a general substitute for application-level backups.

Metadata-only journaling protects allocation maps, inodes, and directories while reducing write traffic. Ordered journaling ensures that data blocks are written before metadata that points to them is committed. Full data journaling records both data and metadata, offering stronger protection against stale contents but usually imposing greater overhead.

A journal typically follows a transaction sequence: gather related updates, write a log record, ensure the log reaches persistent storage, mark or infer the transaction as committed, and later checkpoint changes to their home locations. Recovery scans the journal, replays committed transactions, and reconstructs free-space and metadata structures. The design must address journal capacity, repeated crashes, torn writes, checksums, and device-cache behavior.

Journaling does not protect against all failures. It may not restore accidentally deleted files, corrupted application data, ransomware, or destruction of the storage device. Backups, snapshots, replication, access control, and tested restoration procedures remain necessary.

Log-Structured and Copy-on-Write Designs

A log-structured file system treats storage as a log and writes new versions sequentially, including metadata. Sequential writing can improve utilization of small writes and is well suited to workloads with many updates. Cleaning is required: live blocks are identified, moved, and obsolete segments are reclaimed. Cleaning cost and write amplification can become significant, especially when data has a long lifetime and is scattered across segments.

Copy-on-write (COW) file systems never overwrite blocks that belong to a committed version. Instead, modified data and metadata are written elsewhere, and a new root is installed when the update is complete. Older roots remain available for snapshots. COW supports efficient snapshots, checksumming, and strong protection against partial in-place updates. Its costs include metadata amplification, fragmentation, space-management complexity, and the need to control snapshot growth.

Journaling and COW are not identical. Journaling records a transaction to make in-place structures recoverable; COW creates a new consistent structure while preserving the old one. Hybrid systems may combine journaling, COW metadata, checksums, compression, deduplication, or replication.

RAID and Storage Reliability

RAID combines multiple drives to improve performance, capacity, availability, or some combination of these goals. Striping divides data across drives. Mirroring stores duplicate copies. Parity stores calculated redundancy that can reconstruct missing data.

RAID 0 stripes data without redundancy and therefore improves parallel throughput but increases the probability that a drive failure destroys the array. RAID 1 mirrors data, providing straightforward recovery and good read availability at approximately half the raw capacity. RAID 5 uses distributed single parity and tolerates one drive failure; RAID 6 uses dual parity and tolerates two. RAID 10 combines mirroring and striping, often providing strong random-write performance and predictable rebuild behavior at higher capacity cost.

RAID is not a backup. It does not protect against deletion, malicious encryption, application corruption, fire, or a faulty process that writes bad data to every replica. Rebuilds also impose substantial load and expose the array to additional failures. Large modern disks make rebuild duration and unrecoverable read errors important design considerations. Administrators should evaluate failure domains, hot spares, scrubbing, controller behavior, and monitoring rather than selecting a RAID level from capacity alone.

SSDs, Flash Translation, and Persistent Media

An SSD typically exposes logical block addresses while internally managing flash pages, erase blocks, mapping tables, wear leveling, bad-block management, and garbage collection. Flash pages are written in units different from erase blocks; erasure is slower and occurs at a larger granularity. Consequently, overwriting a small logical region may involve reading valid neighboring data, writing a new physical page, and later erasing and reclaiming an entire block.

Write amplification is the ratio of physical media writes to host-requested writes. It increases with random updates, near-full devices, insufficient over-provisioning, and long-lived snapshots. The TRIM or discard operation allows the device to learn that logical blocks are no longer needed, although its timing and implementation vary.

SSDs provide low access latency and high parallelism, but they are not immune to wear, controller failure, firmware defects, power-loss corruption, or data-retention problems. Enterprise deployments may use power-loss protection so that acknowledged writes in volatile components can be safely committed. Storage procurement should therefore consider endurance ratings, latency under sustained load, protection against sudden power loss, firmware management, and observability.

An Applied Case: Protecting a University Research Repository

Background

A university research group maintains a repository containing experimental measurements, analysis scripts, virtual-machine images, and published datasets. The repository uses a high-capacity redundant storage array and serves both interactive users and automated data-ingestion jobs.

Situation and Problem

Users report that large uploads are fast, but the system becomes unresponsive during snapshot creation and array rebuilds. After a power interruption, one recently updated configuration file reverts to an older version. The administrators initially assume that RAID guarantees both durability and backup.

Analysis

The workload mixes sequential large-file writes, small metadata updates, random reads from virtual-machine images, and long-lived snapshots. The page cache and device cache absorb writes, so application completion does not necessarily mean media persistence. Snapshots retain old blocks in a COW design, increasing space consumption and write amplification. RAID protects against selected drive failures but not against accidental deletion or a logically corrupted file. Rebuild traffic competes with normal requests and may increase latency.

Approach and Solution

The team separates workloads into storage pools, limits snapshot retention, and reserves capacity for COW metadata and garbage collection. It uses extent-friendly allocation and monitors fragmentation, queue depth, latency percentiles, free space, SSD endurance, and rebuild progress. Configuration updates follow a temporary-file, synchronization, and atomic-rename procedure. The system enables power-loss protection and verifies that flush and barrier commands are honored. Nightly versioned backups are copied to a separate failure domain, with periodic restoration tests. RAID scrubbing and checksummed data are scheduled during controlled periods rather than being treated as optional maintenance.

Outcome

Interactive latency becomes more predictable during rebuilds, configuration updates survive controlled power-loss tests, and the repository can recover from accidental deletion as well as a drive failure. The system still documents residual risks, including site-wide disaster and malicious credential use.

Learning Points

The case illustrates that performance, consistency, availability, and recoverability are separate design objectives. RAID is an availability mechanism, not a complete data-protection strategy. Correct persistence requires coordination among applications, the operating system, the file system, the device, and operational procedures.

Challenges, Governance, and Professional Practice

File systems fail through both hardware and software mechanisms. Common technical risks include corrupted metadata, silent data corruption, firmware defects, full volumes, exhausted SSD endurance, unsafe removal, incorrect permissions, stale snapshots, and untested recovery procedures. A nearly full volume can cause pathological allocation and snapshot behavior even when no individual component is defective.

Security requires least-privilege access, ownership and permission controls, encryption where appropriate, secure deletion policies, audit logging, and protection against path traversal and symbolic-link races. Encryption at rest reduces exposure after device theft, but key loss can make data unrecoverable. Retention schedules must balance legal obligations, research reproducibility, privacy, and storage cost. Personal or regulated data should not be copied into unmanaged snapshots and backups without appropriate controls.

Automation improves consistency when it is observable and reversible. Monitoring should include capacity, inode or metadata utilization, cache pressure, latency, error rates, checksum failures, SMART or device-health indicators, replication lag, and backup success. Alerting without restoration exercises creates false confidence. A professional storage service defines recovery-point and recovery-time objectives, assigns ownership, documents dependencies, and tests failure scenarios.

Current Directions

Contemporary systems increasingly combine local flash, persistent-memory technologies, distributed object stores, and cloud-managed block storage. Zoned storage exposes placement constraints that can reduce device-level write amplification when software is designed accordingly. NVMe increases parallelism and lowers protocol overhead, making queue management and tail latency more significant.

Checksummed end-to-end data paths are receiving greater attention because detecting corruption only at the device boundary may be too late. Copy-on-write snapshots, erasure coding, deduplication, compression, and policy-driven tiering support large-scale data management, but each introduces metadata, CPU, capacity, or recovery costs. Machine-learning techniques may assist anomaly detection and predictive maintenance, yet automated decisions must be explainable enough for incident response and must not replace verified backups or sound recovery design.

Best-Practice Design Principles

A robust persistent-storage design should:

1. define what “successful write” and “durable” mean for each application;

2. select allocation and caching policies according to workload rather than fashion;

3. preserve locality while monitoring fragmentation and free-space headroom;

4. use atomic update patterns for critical files and synchronize required metadata;

5. choose RAID or replication according to failure domains and rebuild risk;

6. distinguish high availability from backup, archival retention, and disaster recovery;

7. use checksums, scrubbing, health monitoring, and tested restoration;

8. account for SSD endurance, garbage collection, power-loss behavior, and write amplification;

9. protect data through least privilege, encryption, auditing, and controlled retention;

10. document assumptions and test crashes, device failures, full-volume conditions, and operator mistakes.

Chapter Summary

File systems transform physical storage into persistent abstractions based on files, directories, metadata, and logical offsets. Allocation methods—including extents, linked structures, and indexed designs—determine how files occupy storage and how efficiently they grow and are accessed. Free-space management and locality strongly influence performance and fragmentation.

The storage-I/O path uses caching, buffering, read-ahead, scheduling, and device queues, but these optimizations make persistence semantics subtle. Visibility, atomicity, ordering, and durability are distinct properties. Journaling restores file-system invariants after crashes; log-structured systems write updates sequentially; and copy-on-write systems preserve older consistent versions. RAID improves availability or performance but is not a backup. SSDs require attention to flash translation, endurance, garbage collection, write amplification, and power-loss protection. Sound practice combines technical mechanisms with governance, monitoring, security, backups, and tested recovery.

Key Terms

File: A named persistent sequence of bytes or structured data.

Directory: A namespace structure mapping names to file-system objects.

Inode: A persistent metadata object containing file attributes and data-location information.

Extent: A contiguous range of storage blocks represented by a start and length.

Fragmentation: Inefficient distribution of allocated or free storage space.

Sparse file: A file whose unoccupied logical regions consume little or no physical space.

Page cache: Main-memory cache holding file data and reducing device accesses.

Write-back cache: A cache that delays media writes to improve performance.

Durability: Survival of an update across a specified failure.

Atomicity: The property that an operation appears wholly completed or not completed.

Journal: A log of updates used to recover consistent file-system state.

Checkpoint: The process of applying logged updates to their normal storage locations.

Copy-on-write: A technique that writes modified data to new locations instead of overwriting committed blocks.

Log-structured file system: A file system that organizes updates as an append-oriented log.

RAID: A method of combining drives for performance, capacity, or redundancy.

Write amplification: The ratio of physical storage writes to host-requested writes.

TRIM: A command indicating that logical blocks are no longer needed by the host.

Snapshot: A point-in-time view of data, often implemented through copy-on-write.

Recovery point objective: The maximum acceptable amount of data loss measured in time.

Recovery time objective: The target time for restoring a service after failure.

Review Questions

Short Answer Questions

1. How does a file abstraction separate applications from physical storage?

2. What is the difference between a hard link and a symbolic link?

3. Why can a successful write system call fail to imply durable storage?

4. What problem does a journal address after a system crash?

5. Define write amplification in an SSD.

Long Answer Questions

1. Compare contiguous, linked, indexed, and extent-based allocation with respect to access performance, growth, fragmentation, and metadata overhead.

2. Explain how page caching, buffering, write ordering, and synchronization operations affect file-system consistency and durability.

3. Describe journaling, log-structured, and copy-on-write file systems, emphasizing their recovery models and performance trade-offs.

4. Compare RAID 0, RAID 1, RAID 5, RAID 6, and RAID 10 for a mixed research-storage workload.

5. Explain the internal behavior of SSDs and discuss its implications for garbage collection, endurance, TRIM, and write amplification.

Analytical / Application Questions

1. Design a storage and recovery architecture for a database that requires low-latency writes, protection from sudden power loss, and recovery from accidental deletion. Justify each layer of the design.

2. A COW file system is nearly full, has many long-lived snapshots, and exhibits high write latency. Analyze the likely causes and recommend an operational remedy.

3. An administrator argues that a RAID 6 array eliminates the need for backups. Evaluate the claim and propose a complete protection and recovery policy.

22. Multiple Choice Questions with Answers

Question 1

Which allocation method provides efficient random access while allowing a file to occupy multiple noncontiguous regions?

A. Linked allocation

B. Extent-based allocation

C. Pure contiguous allocation

D. Unstructured free-list allocation

Correct Answer: B. Extent-based allocation

Question 2

A program writes a new configuration file and atomically renames it over the old file. What additional concern is essential for durability?

A. Disabling all directory permissions

B. Synchronizing relevant file data and directory metadata

C. Converting the file to a symbolic link

D. Using RAID 0 exclusively

Correct Answer: B. Synchronizing relevant file data and directory metadata

Question 3

What is the primary purpose of metadata journaling?

A. To guarantee recovery from accidental deletion

B. To increase SSD erase-block size

C. To restore file-system metadata invariants after a crash

D. To replace off-site backups

Correct Answer: C. To restore file-system metadata invariants after a crash

Question 4

Which statement best distinguishes RAID from backup?

A. RAID always provides protection from ransomware

B. RAID improves selected failure availability but does not preserve independent historical copies

C. Backup cannot protect against accidental deletion

D. RAID eliminates the need for monitoring

Correct Answer: B. RAID improves selected failure availability but does not preserve independent historical copies

Question 5

Why can random small writes increase SSD write amplification?

A. They may require relocation of valid data during flash-block reclamation

B. They eliminate all garbage collection

C. They force every read to become sequential

D. They reduce the number of physical writes below host writes

Correct Answer: A. They may require relocation of valid data during flash-block reclamation

Question 6

Which property concerns whether an update survives a power failure?

A. Visibility

B. Atomicity

C. Durability

D. Namespace resolution

Correct Answer: C. Durability

Question 7

A copy-on-write file system creates a new consistent root after writing modified blocks. What benefit follows directly from this design?

A. Older versions can support snapshots

B. All writes become free of metadata overhead

C. Drive failures become impossible

D. Free-space management is unnecessary

Correct Answer: A. Older versions can support snapshots

Question 8

What is the principal trade-off of RAID 0?

A. Redundancy is increased at the cost of capacity

B. Performance and aggregate capacity may improve, but a single drive failure can destroy the array

C. It requires dual parity calculations

D. It cannot serve sequential workloads

Correct Answer: B. Performance and aggregate capacity may improve, but a single drive failure can destroy the array

Question 9

A storage system reports that applications complete writes quickly, but data disappears after sudden power loss. Which explanation is most plausible?

A. The writes remained in volatile caches

B. The directory tree was too shallow

C. The files used extents

D. The device performed read-ahead

Correct Answer: A. The writes remained in volatile caches

Question 10

Why are long-lived snapshots potentially harmful to a nearly full COW file system?

A. They release all old blocks immediately

B. They retain old blocks and increase space use and future write costs

C. They disable all checksums

D. They convert metadata into hard links

Correct Answer: B. They retain old blocks and increase space use and future write costs