4. Filesystems and Storage Management

Introduction and Context

Linux treats persistent storage as a set of abstractions rather than as a collection of directly accessed disks. Applications see files, directories, permissions, and paths; the operating system maps these objects through filesystems, block devices, logical volumes, and storage drivers to physical media. Effective administration therefore requires more than knowing commands such as `cp`, `mount`, or `df`. It requires understanding how naming, allocation, protection, redundancy, encryption, and recovery interact.

A filesystem provides the structures and rules used to store and retrieve data. Storage management determines how that filesystem is placed on disks, combined into larger units, protected against failure, monitored, expanded, and recovered. A poor decision at one layer can undermine the others: a reliable RAID array does not replace backups, encryption does not correct faulty permissions, and a snapshot is not automatically an independent disaster-recovery copy.

This chapter examines the Linux filesystem hierarchy, inodes and links, permissions, mounting, and the principal filesystems used in contemporary Linux systems—ext4, XFS, and Btrfs. It then develops a practical storage-management workflow covering partitioning, LVM, RAID, encryption, quotas, snapshots, backup, and recovery.

Learning Objectives

After studying this chapter, the reader should be able to:

• interpret the Linux filesystem hierarchy and explain the role of inodes, directory entries, and links;
• apply Linux ownership, permission, ACL, and special-bit mechanisms appropriately;
• explain mounting, `/etc/fstab`, and filesystem identification;
• compare ext4, XFS, and Btrfs according to workload and operational requirements;
• design and administer partitions, LVM volumes, software RAID, and encrypted storage;
• distinguish availability mechanisms from backup and recovery mechanisms;
• use quotas, snapshots, monitoring, and integrity checks in production environments;
• evaluate operational, security, governance, and recovery risks in storage designs.

The Linux Storage Model

A useful model separates storage into four layers. At the bottom are physical devices such as hard disks, solid-state drives, SAN LUNs, and virtual disks. A partition table divides a device into regions. Above partitions may sit device-mapper technologies such as LVM, encryption, or multipath storage. Finally, a filesystem organizes blocks into files and directories and is mounted into the unified directory tree.

Linux does not normally expose separate drive letters. Instead, one filesystem becomes the root filesystem, mounted at `/`, and other filesystems are attached at directories such as `/home`, `/var`, or `/srv`. A pathname is therefore a route through directory entries, not a statement about a particular disk. The command `findmnt` displays the current mount topology, while `lsblk -f` associates block devices with filesystem types, labels, and UUIDs.

The filesystem hierarchy follows the Filesystem Hierarchy Standard, although distributions may vary. `/boot` contains bootloader and kernel files; `/etc` stores host configuration; `/usr` contains most user-space programs and libraries; `/var` holds changing data such as logs, caches, queues, and databases; `/home` contains users' personal data; `/tmp` is intended for temporary files; `/dev` exposes device nodes; `/proc` and `/sys` provide kernel and hardware views through virtual filesystems; and `/run` contains volatile runtime state. The distinction between `/usr` and `/var` is operationally important: programs are relatively stable, whereas logs, package databases, spool files, and application state change frequently.

A full filesystem can prevent services from writing logs, creating sockets, or updating databases. Administrators often place high-growth areas such as `/var` or database data on separate filesystems so that exhaustion does not incapacitate the entire system. This is a containment strategy, not a substitute for monitoring.

Inodes, Directory Entries, and Links

A file is represented internally by an inode. An inode stores metadata such as the file type, ownership, permissions, timestamps, link count, and pointers or extents describing the data blocks. The filename is not stored in the inode. A directory is a special file containing mappings from names to inode numbers. This distinction explains several important Linux behaviors.

A hard link is an additional directory entry referring to the same inode. Consequently, two hard-linked names identify the same file contents and metadata. Removing one name decreases the inode's link count but does not remove the data while another hard link or an open file descriptor remains. Hard links generally cannot cross filesystem boundaries and are normally not created for directories, because directory hard links could create ambiguous cycles.

A symbolic link is a separate file containing a pathname to another object. It has its own inode and can cross filesystem boundaries. If its target is removed, the symbolic link becomes dangling. Symbolic links are useful for configurable locations and version switching, but they can introduce security problems when privileged programs follow attacker-controlled paths.

The command `df` reports filesystem-level space, whereas `du` estimates space consumed by directory trees. These values can differ when deleted files remain open: their directory entries are gone, but their blocks remain allocated until the process closes the file. `lsof +L1` can help identify such files. Inode exhaustion is a different failure: a filesystem may have free data space but no available inodes for new files, a situation common with workloads producing millions of small objects.

Permissions, Ownership, and Access Control

Every ordinary Linux file has a user owner, a group owner, and a mode. The mode contains a file-type indicator and permissions for the owner, group, and others. Read permission allows reading file contents; write allows modification; execute allows execution for a regular file. For directories, read permits listing names, write permits creating or removing directory entries, and execute permits traversal and access to entries whose names are known. Directory write permission without execute permission is therefore not equivalent to unrestricted file manipulation.

Symbolic modes such as `u+x,g-w,o-r` express changes, while octal modes such as `0640` encode permission bits. The `umask` subtracts default permissions when new objects are created. Ownership is changed with `chown`, group ownership with `chgrp`, and permissions with `chmod`. Administrators should prefer the least privilege necessary rather than broad modes such as `777`.

Three special mechanisms extend ordinary permissions. The set-user-ID bit causes an executable to run with its owner's effective identity; set-group-ID similarly affects group identity. On a directory, set-group-ID causes newly created entries to inherit the directory's group, which is valuable for collaborative projects. The sticky bit on a directory restricts deletion of entries to the file owner, directory owner, or a privileged user; `/tmp` commonly uses it.

Access control lists (ACLs) provide additional user- and group-specific permissions beyond the single owner and group fields. They are useful when a project requires several overlapping access groups. However, an ACL mask limits the effective permissions of named users, named groups, and the owning group. `getfacl` and `setfacl` should be used to inspect and manage ACLs. Security design must also account for parent-directory traversal, symbolic links, process privileges, and mandatory access-control frameworks such as SELinux or AppArmor.

Mounting and Filesystem Identity

A filesystem becomes accessible when mounted on a directory called its mount point. The `mount` command can mount a device, UUID, or label; `umount` detaches it. Unmounting fails when processes have working directories, open files, or active references within the mount. Before maintenance, `findmnt`, `lsof`, and `fuser` help identify users of the filesystem.

Persistent mounts are normally declared in `/etc/fstab`. A robust entry commonly uses a UUID rather than `/dev/sdX`, because device names can change with hardware discovery order. For example:

```text

UUID=xxxx-xxxx /srv/data xfs defaults,nodev 0 2

```

The options should reflect the workload. `ro` creates a read-only mount; `nosuid` ignores set-user-ID and set-group-ID bits; `nodev` prevents device-node interpretation; and `noexec` restricts execution, although it is not a complete security boundary. The final fields historically control dump and filesystem-check order. After editing `fstab`, `mount -a` can test entries, but administrators should validate carefully because an invalid boot-time entry may affect system startup.

A filesystem's usable capacity is influenced by reserved blocks, metadata, snapshots, and allocation policies. `df -h` provides a human-readable capacity view; `du -x` restricts analysis to one filesystem; and `stat` reveals object metadata. Capacity planning should track both percentage utilization and growth rate.

Comparing ext4, XFS, and Btrfs

ext4

ext4 is a mature general-purpose filesystem and a common default for Linux installations. It uses extents to represent contiguous ranges of blocks, supports journaling, delayed allocation, online growth, and large filesystems. Its operational behavior is familiar, tooling is widely available, and recovery procedures are well understood. It is often a sound choice for operating-system volumes, general servers, and environments that prioritize maturity and broad compatibility.

The journal primarily protects filesystem metadata consistency after a crash; it does not guarantee that every recently written application record is durable. Application-level durability still depends on write ordering, synchronization, and the application's storage protocol.

XFS

XFS is a high-performance, journaling filesystem designed for large filesystems and parallel workloads. It uses allocation groups to support scalability and efficient concurrent allocation. XFS can grow online but generally cannot be shrunk in place. This asymmetry must influence capacity planning: if a volume may need to become smaller, administrators should use a migration strategy rather than assuming a shrink operation exists.

XFS is frequently selected for large files, media, scientific data, virtualization, and enterprise application servers. Its repair tool, `xfs_repair`, is normally used on an unmounted filesystem. As with all filesystems, repair is not a replacement for backup.

Btrfs

Btrfs is a copy-on-write filesystem that integrates checksums, subvolumes, writable snapshots, send/receive replication, and flexible allocation. Copy-on-write preserves older blocks when modified, making snapshots efficient initially. Checksums help detect silent corruption, and scrub operations can verify stored data; correction requires an appropriate redundant configuration or a reliable replacement copy.

Btrfs subvolumes provide independently manageable filesystem trees without requiring separate partitions. Snapshots can support rapid rollback and testing, while send/receive can transfer snapshot differences to another filesystem. These features introduce operational complexity: snapshot retention consumes space, copy-on-write can affect fragmentation and database performance, and administrators must understand the distinction between subvolumes, snapshots, and independent backups.

The choice among these filesystems is a workload decision. Maturity, shrink requirements, large-file performance, snapshot needs, integrity checking, tooling, and organizational expertise should all be evaluated rather than relying on popularity alone.

From Disks to Managed Storage

Partitioning

A partition table, commonly GPT on modern systems, defines block-device regions. Partitioning may separate boot requirements, operating-system data, application data, and recovery space, but excessive partitioning can create stranded capacity. Before modifying a partition, administrators must identify the correct device with `lsblk`, `blkid`, and possibly `udevadm`; a mistaken partition command can destroy data immediately.

A typical workflow is to create a partition, notify the kernel if necessary, initialize it as a physical volume or filesystem, assign a stable identifier, and test the resulting mount. Partition alignment and sector sizes matter for performance, particularly with SSDs and advanced-format disks, though modern tools generally align partitions correctly when used with appropriate defaults.

Logical Volume Management

LVM inserts an abstraction between partitions or disks and filesystems. Physical volumes (PVs) are combined into a volume group (VG), from which logical volumes (LVs) are allocated. An LV can be extended without changing the application's path, and many filesystems can then be grown online. `pvs`, `vgs`, and `lvs` provide inventory; `pvcreate`, `vgcreate`, and `lvcreate` construct the layers.

LVM separates capacity allocation from physical layout. It can pool disks, create thin-provisioned volumes, and provide snapshots. Thin provisioning, however, can overcommit storage: logical capacity may exceed physical capacity, and exhaustion of the pool can affect multiple volumes. Monitoring must therefore include both virtual allocation and actual pool consumption.

A safe growth procedure is to verify free extents, extend the LV, and then grow the filesystem using the filesystem-specific tool. Shrinking is more hazardous: the filesystem is normally reduced first, while unmounted or offline where required, and only then is the LV reduced. Reversing this order truncates data.

RAID and Availability

RAID combines devices to improve performance, capacity, or fault tolerance. RAID 0 provides striping without redundancy. RAID 1 mirrors data and tolerates device loss according to the layout. RAID 5 uses distributed parity but has write, rebuild, and failure-related trade-offs; RAID 6 adds another parity level. RAID 10 combines mirroring and striping and is often attractive for write-intensive workloads.

Linux software RAID is administered with `mdadm`. RAID improves availability after certain device failures, but it is not a backup: accidental deletion, malware, application corruption, and some controller or operator failures are replicated across the array. Rebuilds also impose performance and risk costs, especially on large disks. Monitoring should detect degraded arrays promptly, and replacement procedures should be tested rather than assumed.

Encryption

Full-volume or block-device encryption is commonly implemented with LUKS and `cryptsetup`. It protects data at rest when the device is not unlocked, but it does not protect data from an attacker who has obtained access to a running, unlocked system. Key management is therefore as important as the encryption algorithm. Recovery keys must be stored securely, access should be separated by role where practical, and backup copies must be encrypted and tested.

Encryption can be layered with LVM, for example by placing a volume group inside an encrypted device, or by encrypting selected filesystems or directories. The design should account for boot availability, remote unlocking, key rotation, performance, and the risk that encrypted backups become permanently unusable if keys are lost.

Quotas, Snapshots, Backup, and Recovery

Quotas limit consumption by user, group, or project. They are valuable on multi-user systems, shared research platforms, and hosting environments. A soft limit may be exceeded temporarily, while a hard limit is enforced more strictly. Quotas must be combined with monitoring because metadata, reserved space, and administrative processes can produce confusing capacity reports.

A snapshot records a point-in-time view. LVM snapshots copy changed blocks through copy-on-write; Btrfs snapshots operate at the subvolume level; storage arrays may provide hardware snapshots. Snapshots are excellent for short-term rollback, testing, and consistent backup preparation. They are not sufficient as the only backup because they may share the same disks, controller, power domain, or administrative credentials as the source. Excessive retention can also exhaust storage.

A backup is an independently managed copy from which data can be restored. A useful policy defines recovery point objective (RPO), the maximum acceptable data loss measured in time, and recovery time objective (RTO), the target time for restoring service. Full, incremental, and differential methods have different storage and restoration characteristics. Deduplication and compression reduce storage costs but add processing and recovery dependencies.

Database backups must respect application consistency. Copying live database files at arbitrary moments may produce an unusable set even when the filesystem snapshot is internally consistent. Administrators should use database-native backup mechanisms, coordinated snapshots, or application quiescence. The 3-2-1 principle—multiple copies, on different media, with at least one copy separated from the primary environment—is a useful baseline, but it must be adapted to threat models and regulatory obligations.

Recovery is a process, not merely the existence of backup files. It includes identifying the incident, preserving evidence where necessary, selecting a recovery point, rebuilding or validating the target environment, restoring data, checking application integrity, and documenting the result. Restoration drills reveal missing credentials, incompatible versions, inadequate bandwidth, and unrecorded dependencies.

An Illustrative Case: Consolidating a Research Data Platform

Background

A university research group operates a Linux server that stores instrument output, analysis results, and user home directories. The original system uses a single filesystem on two mirrored disks. Researchers report slow analysis, the filesystem periodically reaches capacity, and backups have never been restored in a test.

Situation and Analysis

The data includes many small metadata files, very large raw instrument files, and active project databases. The group requires an RPO of 24 hours and an RTO of eight hours. A single mirrored array protects against some disk failures but not deletion, ransomware, or filesystem corruption. A single filesystem also allows temporary data and logs to consume space needed by critical services.

Strategy and Solution

The administrators inventory growth using `df`, `du`, and inode statistics, then classify data by performance, retention, and sensitivity. They create separate storage areas for the operating system, user homes, project data, and transient analysis output. LVM is placed over a monitored storage pool to permit controlled expansion. A mature filesystem is selected for general project data, while a Btrfs subvolume is used for a workload that benefits from frequent snapshots and send/receive replication; the choice is documented and tested rather than applied uniformly.

Sensitive project data is encrypted at rest with LUKS. Group ownership, set-group-ID project directories, ACLs, and quotas implement collaborative access and prevent one researcher from consuming all capacity. RAID provides local availability, but scheduled backups transfer encrypted copies to a separate system and an off-site location. Databases use native consistent backups. Snapshots are retained for short-term recovery only.

Outcome

The design isolates capacity failures, makes growth observable, and provides multiple recovery paths. A quarterly restoration exercise confirms that files, permissions, database consistency, encryption keys, and service configuration can all be recovered within the target time.

Learning Points

The central lesson is architectural: filesystem selection, storage abstraction, access control, and backup policy must be designed together. RAID and snapshots reduce downtime but do not replace independent backups. A technically sophisticated configuration is valuable only when administrators can monitor, explain, and restore it.

Risks, Governance, and Professional Practice

Common mistakes include formatting the wrong device, reducing an LV before reducing its filesystem, assuming `df` and `du` must match, treating a snapshot as a backup, forgetting to monitor thin pools, and using `777` to solve an ownership problem. Other risks include boot failure caused by an invalid `fstab` entry, leaked encryption keys, untested recovery procedures, stale ACLs, and silent corruption that goes undetected because integrity checks are never scheduled.

Storage administration also has governance implications. Access to user data should follow institutional policy, privacy requirements, and documented authorization. Logs may contain personal or confidential information and should have retention and access rules. Decommissioned disks require approved sanitization or cryptographic erasure. Change management is essential for partitioning, RAID replacement, encryption-key operations, and filesystem upgrades. In regulated environments, evidence of backup success is not equivalent to evidence of successful restoration.

Automation improves consistency when it is idempotent, reviewed, and protected by safeguards. Configuration management can deploy mount definitions, quotas, and monitoring; scripts can alert on capacity, inode use, RAID degradation, and snapshot growth. Automated destructive commands require device identity checks, confirmation gates, and tested recovery paths. Emerging storage practice increasingly combines immutable backups, remote attestation, policy-driven encryption, and observability platforms, but these tools do not eliminate the need for sound fundamentals.

Best-Practice Workflow

A disciplined storage change generally follows this sequence:

1. Define workload, capacity, performance, availability, RPO, and RTO requirements.

2. Inventory devices, mounts, filesystems, ownership, growth, and current backups.

3. Select a filesystem and storage layers appropriate to the requirements.

4. Record device identities and configuration before making changes.

5. Create partitions, encryption mappings, RAID, LVM, and filesystems in a verified order.

6. Apply least-privilege permissions, ACLs, quotas, and secure mount options.

7. Test mounting, growth, failure handling, monitoring, and application behavior.

8. Implement independent backups and perform documented restoration exercises.

9. Monitor capacity, inode usage, integrity, latency, RAID state, encryption availability, and backup results.

10. Review the design after workload, software, hardware, or regulatory changes.

Chapter Summary

Linux storage is organized as layers: physical devices and partitions support abstractions such as RAID, encryption, and LVM, which in turn host filesystems mounted into one directory tree. Inodes store metadata and block references, while directory entries associate names with inodes; this explains hard links, symbolic links, open deleted files, and inode exhaustion. Permissions, special bits, ACLs, and security frameworks govern access.

ext4 offers mature general-purpose behavior, XFS provides scalable performance but cannot normally shrink in place, and Btrfs integrates copy-on-write, checksums, subvolumes, and snapshots with additional operational complexity. LVM provides flexible allocation, RAID improves availability, LUKS protects data at rest, quotas control consumption, and snapshots support short-term rollback. None replaces an independent, tested backup. Sound administration joins technical design with monitoring, governance, key management, change control, and restoration practice.

Key Terms

Inode: Filesystem structure containing metadata and references to a file's data blocks.

Directory entry: Mapping between a filename and an inode number.

Hard link: A directory entry that refers to an existing inode.

Symbolic link: A special file containing a pathname to another object.

Mount point: Directory at which a filesystem is attached to the namespace.

UUID: Persistent identifier assigned to a storage object or filesystem.

ACL: Extended access-control mechanism supporting additional users and groups.

Set-group-ID: Permission bit that affects executable group identity or directory group inheritance.

Sticky bit: Directory permission that restricts deletion of entries.

Journal: Filesystem mechanism recording operations to aid crash recovery.

Extent: Description of a contiguous range of filesystem blocks.

LVM: Linux Logical Volume Manager, providing pooled and flexible block storage.

Physical volume: Storage device or partition initialized for LVM use.

Volume group: Pool of physical extents from which logical volumes are allocated.

RAID: Technique combining devices for redundancy, performance, or both.

LUKS: Standard Linux format for encrypted block-device containers.

Quota: Limit on storage consumption by user, group, or project.

Snapshot: Point-in-time view maintained through copy-on-write or storage-layer mechanisms.

RPO: Maximum acceptable period of data loss after an incident.

RTO: Target time for restoring service after an incident.

Review Questions

Short Answer Questions

1. Why can `df` and `du` report different amounts of used space?

2. Distinguish a hard link from a symbolic link.

3. What is the purpose of using a UUID in `/etc/fstab`?

4. Why is RAID not a substitute for backup?

5. What does a filesystem journal protect, and what does it not guarantee?

Long Answer Questions

1. Explain the Linux storage stack from physical device to mounted filesystem, including the roles of partitioning, LVM, encryption, and RAID.

2. Compare ext4, XFS, and Btrfs for a university research server with large files, snapshots, and long-term operational requirements.

3. Explain Linux permissions, special bits, ACLs, and the security implications of symbolic links.

4. Describe a safe procedure for extending and, where supported, shrinking an LVM-backed filesystem.

5. Design a backup and recovery strategy using RPO, RTO, snapshots, independent backups, and restoration testing.

Analytical / Application Questions

1. A server reports 20% free filesystem space, but an application cannot create files because the filesystem has exhausted inodes. Diagnose the situation and propose corrective actions.

2. A database administrator proposes keeping only hourly snapshots on the same RAID array as the database. Evaluate the proposal and redesign it for protection against deletion, corruption, and array failure.

3. A company needs encrypted, collaborative project storage with quotas, online expansion, and recovery after ransomware. Propose a layered Linux storage architecture and justify the major design choices.

22. Multiple Choice Questions with Answers

Question 1

Which statement best explains why deleting a filename may not immediately free its disk blocks?

A. The directory is always mounted read-only

B. Another hard link or an open file descriptor still references the inode

C. The symbolic link is automatically recreated

D. The filesystem journal permanently preserves the data

Correct Answer: B. Another hard link or an open file descriptor still references the inode

Question 2

A Linux administrator wants a persistent mount that remains stable if device discovery order changes. Which identifier is most appropriate?

A. The temporary `/dev/sdX` name

B. The process ID of the mounting service

C. The filesystem UUID

D. The inode number of the mount point

Correct Answer: C. The filesystem UUID

Question 3

What is the principal operational limitation of XFS highlighted in this chapter?

A. It cannot store large files

B. It cannot normally be shrunk in place

C. It provides no journaling

D. It cannot be mounted through `/etc/fstab`

Correct Answer: B. It cannot normally be shrunk in place

Question 4

An organization needs short-term rollback and protection from ransomware that destroys the primary storage array. Which design is strongest?

A. Keep snapshots only on the same array

B. Use RAID 0 and no backups

C. Use local snapshots plus independent, preferably isolated backups

D. Increase the filesystem reserved-block percentage

Correct Answer: C. Use local snapshots plus independent, preferably isolated backups

Question 5

What is the correct general order when reducing an LVM-backed filesystem?

A. Reduce the LV first, then reduce the filesystem

B. Reduce the filesystem first, then reduce the LV

C. Delete the volume group, then resize the filesystem

D. Unmount the physical disk without resizing either layer

Correct Answer: B. Reduce the filesystem first, then reduce the LV

Question 6

Which permission is required on a directory to traverse it and access an entry when its name is known?

A. Execute

B. Write only

C. Read only

D. Set-user-ID

Correct Answer: A. Execute

Question 7

What is a major risk of LVM thin provisioning?

A. It prevents all filesystem snapshots

B. Logical capacity can be allocated beyond physical capacity, causing pool exhaustion

C. It removes the need for monitoring

D. It automatically encrypts all logical volumes

Correct Answer: B. Logical capacity can be allocated beyond physical capacity, causing pool exhaustion

Question 8

Which statement most accurately describes Btrfs snapshots?

A. They are always independent copies on separate hardware

B. They use copy-on-write and may consume additional space as data changes

C. They replace application-consistent database backups in every case

D. They can only be created for the root filesystem

Correct Answer: B. They use copy-on-write and may consume additional space as data changes

Question 9

What does the recovery point objective primarily measure?

A. The time required to rebuild a RAID array

B. The maximum acceptable amount of data loss measured in time

C. The number of users allowed in a project directory

D. The percentage of reserved filesystem blocks

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 10

A filesystem has substantial free data space but refuses to create new small files. Which explanation is most plausible?

A. All inodes have been consumed

B. The mount point has too many directory entries by definition

C. The filesystem UUID has changed

D. The sticky bit is enabled

Correct Answer: A. All inodes have been consumed