LFCS 77 🐧 Filesystems — Overview - KandZ

⏱️ Estimated read: 18 min | |

A Linux system administrator does not format a disk “with Linux.” They format it with a specific filesystem, and that choice determines what the storage can do: whether it can shrink, whether it can snapshot, whether it can recover from a power loss without a lengthy check, and how it behaves under concurrent load. The LFCS storage domain expects you to know the major filesystem families, their command-line tools, and the trade-offs that make one appropriate for a root volume and another for a database.

This chapter covers the filesystems that appear in LFCS objectives: ext4, XFS, and Btrfs as the primary local filesystems, with brief treatment of the virtual filesystem layer that unifies them and the special-purpose filesystems that serve roles outside persistent storage. It explains what each filesystem is designed for, the commands that create and manage it, and the limitations that matter in practice. The chapter does not attempt to teach every mount option or every tuning parameter; those belong to dedicated chapters. It aims to give the working administrator enough context to choose correctly and to recognize when a filesystem’s constraints will cause trouble.

Key point: The filesystem choice is constrained by what you need to do later, not by what is fastest at creation time. XFS cannot shrink. ext4 can. Btrfs can snapshot. That single sentence decides most real-world selections.

Why filesystem choice matters

The resize direction problem. A filesystem that cannot shrink is a filesystem that cannot give space back. XFS can be grown online with xfs_growfs, but there is no command to shrink it; the only way to reduce an XFS filesystem is to back up, recreate, and restore . ext4 supports both online growth and offline shrinking. Btrfs supports both directions online. In an environment where logical volumes are resized regularly, the inability to shrink is a genuine operational constraint, not a theoretical one.

The snapshot requirement. A filesystem that can take instant, space-efficient snapshots enables a different style of administration: upgrade a system, snapshot before the change, roll back if it fails. Btrfs provides this as a core feature, with subvolumes and copy-on-write semantics . ext4 and XFS do not. If the requirement is “roll back a failed upgrade in seconds,” the filesystem decision is already made.

The workload profile. XFS was designed for large storage configurations and high-throughput parallel workloads, and it shows its strength on large files and concurrent I/O . ext4 is a general-purpose filesystem with a long history and predictable behavior, but its design descends from the 1980s ext2 lineage, and its free-space management is bitmap-based . Btrfs adds checksums and compression but has a reputation for more variable performance in some workloads . The choice should follow the workload, not the other way around.

The recovery tool. Each filesystem has its own repair command, and the command is not interchangeable. ext4 uses e2fsck, XFS uses xfs_repair, and Btrfs uses btrfs check . An administrator who knows only fsck will be stuck when an XFS volume fails to mount. Knowing which tool to run, and when to run it, is part of filesystem literacy.

The default filesystem of the distribution. The “right” filesystem depends partly on the distribution and its support posture. SUSE has used Btrfs as the default for the operating system since SLE 12, while XFS remains the workhorse for large-scale data volumes . Red Hat and its derivatives have favored XFS for root and data volumes. Debian and Ubuntu have historically defaulted to ext4. An LFCS candidate should be able to work with whatever default the exam environment provides, and to justify a different choice when the default does not fit.

a. The VFS layer and the filesystem families

Linux does not expose filesystems directly to applications. The Virtual Filesystem Switch (VFS) is the kernel abstraction that presents a uniform interface—open, read, write, stat—and dispatches each operation to the filesystem driver that owns the underlying block device or network share . This is why the same cp command works on ext4, XFS, NFS, and procfs: the VFS translates the system call into the filesystem’s specific implementation.

The VFS also explains why filesystem types are categorized by behavior rather than by name. A journaling filesystem records metadata changes in a log before applying them, so that after a crash the kernel can replay or discard the log and bring the filesystem to a consistent state without a full scan. ext4 and XFS are journaling filesystems. Btrfs is not a journaling filesystem in the same sense: it uses copy-on-write, writing new data to new locations and updating the metadata tree only after the write completes, so a crash leaves either the old tree or the new tree intact . The practical difference is that Btrfs does not need a journal replay, but it does need its own consistency checking.

A special filesystem does not store data on a block device at all. /proc exposes kernel and process information. /sys exposes device and driver information. tmpfs stores files in memory. These are mounted through the VFS just like disk filesystems, and they appear in mount output, but they are not candidates for mkfs. The LFCS candidate should recognize them in df -hT output and know that they are not the subject of partitioning or formatting.

The local filesystems that matter for storage management are ext4, XFS, and Btrfs. Each has a creation command, a repair command, and a resize command, and those commands are the practical core of the storage domain.

b. ext4, XFS, and Btrfs in practice

ext4 is the fourth generation of the extended filesystem. It uses extents instead of indirect block maps, which improves performance on large files, and it supports delayed allocation, which allows the filesystem to make better decisions about where to place data . Its tools are the e2fsprogs family: mkfs.ext4 to create, e2fsck to repair, resize2fs to grow or shrink, and tune2fs to adjust parameters such as the reserved block percentage and the mount count between checks . It can be grown online and shrunk offline, which makes it the most flexible of the three for environments where volumes are resized frequently.

# Create an ext4 filesystem on a partition.
sudo mkfs.ext4 /dev/sdb1

# Check and repair an unmounted ext4 filesystem.
# -f forces a check even if the filesystem appears clean.
sudo e2fsck -f /dev/sdb1

# Grow the filesystem to fill its partition.
# The partition must be grown first (parted, lvextend, etc.).
sudo resize2fs /dev/sdb1

# Shrink requires the filesystem to be unmounted.
# The target size must be smaller than the current size.
sudo resize2fs /dev/sdb1 10G

XFS is a 64-bit journaling filesystem originally developed by SGI for IRIX and ported to Linux. It is designed for scalability: large filesystems, large files, and high concurrency. Its allocation-group design distributes metadata across the device, which reduces contention on large systems . Its tools are the xfsprogs family: mkfs.xfs to create, xfs_repair to repair, xfs_growfs to grow, and xfs_admin to change label and UUID . The critical limitation is that XFS cannot shrink. xfs_growfs has no inverse.

# Create an XFS filesystem.
# -f forces creation even if a filesystem signature is detected.
sudo mkfs.xfs -f /dev/sdb1

# Grow the filesystem to the size of its underlying device.
# The device (partition or LV) must be grown first.
sudo xfs_growfs /mnt/data

# Repair an unmounted XFS filesystem.
# -n checks without making changes.
sudo xfs_repair -n /dev/sdb1
sudo xfs_repair /dev/sdb1

# Change the label (maximum 12 characters).
sudo xfs_admin -L "data" /dev/sdb1

Btrfs is a copy-on-write filesystem with integrated volume management, snapshots, subvolumes, checksums, and compression . It does not overwrite data in place; a write goes to a new location, and the metadata tree is updated to point to it. This is what enables snapshots: a snapshot is simply a new tree that references the same data blocks. Its tools are the btrfs command family: mkfs.btrfs to create, btrfs check to repair, btrfs filesystem resize to grow or shrink, and btrfs subvolume snapshot to create snapshots . It is the most feature-rich of the three and the most complex to operate.

# Create a Btrfs filesystem.
sudo mkfs.btrfs /dev/sdb1

# Mount it and create a subvolume.
sudo mount /dev/sdb1 /mnt
sudo btrfs subvolume create /mnt/@data

# Create a read-only snapshot of the subvolume.
sudo btrfs subvolume snapshot -r /mnt/@data /mnt/@data-snap

# Grow or shrink the filesystem.
# The size can be absolute or relative (+1G, -1G, max).
sudo btrfs filesystem resize max /mnt
sudo btrfs filesystem resize -10G /mnt

# Check the filesystem (offline, unmounted).
sudo btrfs check /dev/sdb1

The choice between these three is summarized by a few questions. Does the filesystem need to shrink? If yes, XFS is excluded. Does it need snapshots? If yes, Btrfs is the only local option. Is the workload a large database or a high-concurrency file server? XFS is the conventional choice. Is the workload general-purpose with a long history of predictable behavior? ext4 remains a reasonable default. The LFCS exam does not require a philosophical commitment to any of them; it requires knowing which tool to reach for and why.

c. Special filesystems and the mount table

The mount command without arguments lists every mounted filesystem, including special filesystems. An LFCS candidate should be able to read this output and distinguish the persistent storage from the virtual entries. df -hT is the more compact view: it shows the filesystem type, size, used space, and mount point for each mounted filesystem.

# Show filesystem types alongside mount points.
df -hT

# Typical output includes:
# /dev/sda1   ext4   /        (persistent root)
# /dev/sdb1   xfs    /data    (persistent data)
# tmpfs       tmpfs  /run     (memory-backed, not persistent)
# devtmpfs    devtmpfs /dev   (device nodes)
# proc        proc   /proc    (kernel and process info)

The special filesystems appear in df output but are not formatted, partitioned, or repaired with the tools covered in this chapter. tmpfs stores files in RAM and swap; its contents are lost on reboot. proc and sysfs are kernel interfaces. devtmpfs is populated by the kernel with device nodes. Recognizing them prevents the mistake of trying to run mkfs on a tmpfs mount or wondering why /proc reports zero size.

The /etc/fstab file controls which filesystems are mounted at boot. Each line specifies a device (preferably by UUID), a mount point, a filesystem type, mount options, and two numeric fields for dump and fsck order . The mount -a command mounts everything in fstab that is not already mounted, which is the standard way to test a new entry before rebooting.

# A typical /etc/fstab entry for an ext4 data partition.
# UUID is preferred over device names because it survives device reordering.
UUID=1234-abcd /data ext4 defaults 0 2

# The final field controls fsck order:
# 0 = never check, 1 = root filesystem, 2 = other filesystems.

The fsck order field is filesystem-specific in its behavior. For ext4, a value of 2 means e2fsck runs in parallel with other filesystems at the same order. For XFS, the fsck.xfs binary is a no-op that exits successfully; XFS relies on journal recovery at mount time and on xfs_repair for deeper checks . For Btrfs, fsck.btrfs is similarly a no-op; btrfs check is the real tool. The fstab field still controls boot ordering, but the administrator should know that a value of 2 does not mean the same thing for every filesystem.

Complete Example Session

# ============================================
# PART 1: INSPECTING AVAILABLE FILESYSTEMS
# ============================================
# List the filesystem types the kernel supports.

cat /proc/filesystems
# Look for ext4, xfs, btrfs in the output.

# Show mounted filesystems and their types.
df -hT

# ============================================
# PART 2: CREATING AN EXT4 FILESYSTEM
# ============================================
# Format a partition with ext4 and mount it.

sudo mkfs.ext4 /dev/sdb1
sudo mkdir -p /mnt/ext4
sudo mount /dev/sdb1 /mnt/ext4
df -hT /mnt/ext4

# ============================================
# PART 3: CREATING AN XFS FILESYSTEM
# ============================================
# Format a partition with XFS and mount it.

sudo mkfs.xfs -f /dev/sdb2
sudo mkdir -p /mnt/xfs
sudo mount /dev/sdb2 /mnt/xfs
df -hT /mnt/xfs

# ============================================
# PART 4: CREATING A BTRFS FILESYSTEM
# ============================================
# Format a partition with Btrfs and mount it.

sudo mkfs.btrfs -f /dev/sdb3
sudo mkdir -p /mnt/btrfs
sudo mount /dev/sdb3 /mnt/btrfs
df -hT /mnt/btrfs

# ============================================
# PART 5: THE RESIZE LIMITATION
# ============================================
# XFS cannot shrink. ext4 can shrink offline.
# Btrfs can shrink online. The commands differ.

# ext4: grow online, shrink offline.
sudo resize2fs /dev/sdb1          # grow to partition size
sudo umount /mnt/ext4
sudo resize2fs /dev/sdb1 5G       # shrink to 5G (filesystem must be unmounted)

# XFS: grow only.
sudo xfs_growfs /mnt/xfs          # grow to device size
# sudo xfs_growfs /mnt/xfs -D ... # no shrink equivalent

# Btrfs: grow or shrink.
sudo btrfs filesystem resize max /mnt/btrfs
sudo btrfs filesystem resize -5G /mnt/btrfs

# ============================================
# PART 6: THE REPAIR TOOLS
# ============================================
# Each filesystem has its own repair command.
# All must be run on an unmounted filesystem for full repair.

# ext4
sudo umount /mnt/ext4
sudo e2fsck -f /dev/sdb1

# XFS
sudo umount /mnt/xfs
sudo xfs_repair /dev/sdb2

# Btrfs
sudo umount /mnt/btrfs
sudo btrfs check /dev/sdb3

# ============================================
# PART 7: THE SNAPSHOT DIFFERENCE
# ============================================
# Btrfs snapshots are a core feature.
# ext4 and XFS do not have native snapshots.

sudo mount /dev/sdb3 /mnt/btrfs
sudo btrfs subvolume create /mnt/btrfs/@data
sudo btrfs subvolume snapshot -r /mnt/btrfs/@data /mnt/btrfs/@data-snap

# The snapshot is read-only and references the same data blocks.
sudo btrfs subvolume list /mnt/btrfs

# ============================================
# PART 8: THE FSTAB ENTRY
# ============================================
# Persistent mounts use UUIDs, not device names.
# The type field tells mount which driver to use.

# Get the UUID of a partition.
sudo blkid /dev/sdb1

# Add to /etc/fstab (example):
# UUID=xxxx /mnt/ext4 ext4 defaults 0 2

# Test the entry without rebooting.
sudo mount -a
findmnt /mnt/ext4

# ============================================
# PART 9: THE SPECIAL FILESYSTEMS
# ============================================
# Not every mounted filesystem is a disk filesystem.
# Recognize the virtual ones in df output.

df -hT | grep -E 'tmpfs|proc|sysfs|devtmpfs'

# These are not formatted with mkfs and not repaired with fsck.

# ============================================
# PART 10: THE DECISION SUMMARY
# ============================================
# Choose ext4: general-purpose, shrinkable, predictable.
# Choose XFS: large files, high concurrency, grow-only.
# Choose Btrfs: snapshots, compression, checksums, flexible resize.
# Each has a toolset; none is universally correct.

echo "Filesystem overview complete."

The ten parts walk through creation, mounting, resizing, repair, snapshots, and persistence for the three primary local filesystems. The key observation is that the commands are not interchangeable: each filesystem has its own mkfs variant, its own repair tool, and its own resize behavior. The LFCS exam tests the ability to select the right command for the filesystem in front of you, not to memorize a single universal procedure.

Quick Reference

Filesystem Comparison

Feature	ext4	XFS	Btrfs
Create	`mkfs.ext4`	`mkfs.xfs`	`mkfs.btrfs`
Repair	`e2fsck`	`xfs_repair`	`btrfs check`
Grow online	Yes	Yes	Yes
Shrink online	No	No	Yes
Shrink offline	Yes	No	Yes
Snapshots	No	No	Yes
Max filesystem size	1 EiB	8 EiB	16 EiB

Resize Behavior

Filesystem	Grow Command	Shrink Command	Mount State
ext4	`resize2fs /dev/X`	`resize2fs /dev/X SIZE`	Grow online, shrink unmounted
XFS	`xfs_growfs /mount`	None	Grow online only
Btrfs	`btrfs filesystem resize max /mount`	`btrfs filesystem resize -SIZE /mount`	Either online

Repair Tools

Filesystem	Check Only	Full Repair	Notes
ext4	`e2fsck -n`	`e2fsck -f`	Must be unmounted for full repair
XFS	`xfs_repair -n`	`xfs_repair`	Must be unmounted
Btrfs	`btrfs check --readonly`	`btrfs check`	Offline recommended

Special Filesystems

Filesystem	Purpose	Persistent?
`tmpfs`	RAM-backed storage	No
`proc`	Kernel/process info	No
`sysfs`	Device/driver info	No
`devtmpfs`	Device nodes	No
`overlay`	Container layers	Depends

Best Practices

✅ Do This:

# Know the resize direction before choosing a filesystem.
# If shrinking is required, XFS is the wrong choice.                # ✅

# Use the filesystem-specific repair tool.
sudo xfs_repair /dev/sdb1                                           # ✅

# Use UUIDs in /etc/fstab.
UUID=xxxx /data ext4 defaults 0 2                                   # ✅

# Test fstab entries with mount -a before rebooting.
sudo mount -a                                                       # ✅

# Grow the underlying device before growing the filesystem.
sudo lvextend -L +10G /dev/vg/data && sudo xfs_growfs /data         # ✅

# Recognize special filesystems in df output.
df -hT | grep tmpfs                                                 # ✅

❌ Don’t Do This:

# Don't try to shrink XFS. There is no command for it.
# sudo xfs_growfs -D ...  # does not shrink                              # ❌

# Don't run fsck on a mounted filesystem for full repair.
sudo e2fsck /dev/sdb1  # while mounted                              # ❌

# Don't use device names in fstab.
/dev/sdb1 /data ext4 defaults 0 2  # may change on reboot            # ❌

# Don't assume fsck.xfs or fsck.btrfs do anything useful.
# They are no-ops; use xfs_repair or btrfs check.                    # ❌

# Don't format a special filesystem with mkfs.
sudo mkfs.ext4 /dev/tmpfs  # tmpfs has no block device               # ❌

# Don't choose a filesystem without knowing its repair tool.
# A filesystem you cannot repair is a liability.                     # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Cannot shrink an XFS volume	XFS has no shrink command	Back up, recreate, restore; or choose ext4/Btrfs
`resize2fs` fails	Filesystem is mounted for shrink	Unmount before shrinking ext4
`fsck` does nothing on XFS	`fsck.xfs` is a no-op	Use `xfs_repair` instead
Mount fails after resize	Device grown but filesystem not	Run `xfs_growfs` / `resize2fs` / `btrfs resize`
Wrong filesystem type in fstab	Type field mismatches actual filesystem	Check with `blkid` before writing fstab
Snapshot not found	Btrfs snapshots require subvolumes	Create a subvolume first, then snapshot it
`df` shows full tmpfs	tmpfs size is set at mount	Remount with `size=` option or clear files

Real-World Examples

1. Format ext4

sudo mkfs.ext4 /dev/sdb1

2. Format XFS

sudo mkfs.xfs -f /dev/sdb1

3. Format Btrfs

sudo mkfs.btrfs -f /dev/sdb1

4. Grow ext4

sudo resize2fs /dev/sdb1

5. Grow XFS

sudo xfs_growfs /mnt/data

6. Shrink Btrfs

sudo btrfs filesystem resize -5G /mnt/data

7. Repair ext4

sudo e2fsck -f /dev/sdb1

8. Repair XFS

sudo xfs_repair /dev/sdb1

9. Btrfs Snapshot

sudo btrfs subvolume snapshot -r /mnt/@data /mnt/@data-snap

10. Fstab Entry

UUID=xxxx /data xfs defaults 0 0

Visual

The VFS Layer

┌─────────────────────────────────────────────────────────┐
│  APPLICATION                                            │
│  open(), read(), write(), stat()                        │
│         │                                               │
│         ▼                                               │
│  ┌───────────────────────────────────────────────────┐  │
│  │  VIRTUAL FILESYSTEM SWITCH (VFS)                  │  │
│  │  Uniform interface; dispatches to drivers         │  │
│  └───────────────────────────────────────────────────┘  │
│         │                                               │
│    ┌────┼────────┬────────────┬────────────┐           │
│    ▼    ▼        ▼            ▼            ▼           │
│  ext4  XFS     Btrfs        proc         tmpfs         │
│  (disk)(disk)  (disk)      (kernel)     (memory)       │
│                                                         │
│  The VFS hides the differences. The administrator       │
│  still needs to know them for storage decisions.        │
└─────────────────────────────────────────────────────────┘

Resize Direction Matrix

┌─────────────────────────────────────────────────────────┐
│              GROW              SHRINK                   │
│                                                         │
│  ext4        ✅ online          ✅ offline              │
│              resize2fs          resize2fs (unmounted)   │
│                                                         │
│  XFS         ✅ online          ❌ NEVER                │
│              xfs_growfs         no command              │
│                                                         │
│  Btrfs       ✅ online          ✅ online               │
│              btrfs resize       btrfs resize -size      │
│                                                         │
│  The shrink column is the decision point.               │
│  If shrinking is required, XFS is excluded.             │
└─────────────────────────────────────────────────────────┘

Filesystem Tool Mapping

┌─────────────────────────────────────────────────────────┐
│  TASK         ext4          XFS           Btrfs         │
│  ─────────────────────────────────────────────────────  │
│  Create       mkfs.ext4     mkfs.xfs      mkfs.btrfs    │
│  Check        e2fsck        xfs_repair    btrfs check   │
│  Grow         resize2fs     xfs_growfs    btrfs resize  │
│  Shrink       resize2fs     (none)        btrfs resize  │
│  Label        tune2fs -L     xfs_admin -L btrfs filesys │
│  Snapshot     (none)        (none)        btrfs subvol  │
│                                                         │
│  The tools are not interchangeable.                     │
│  Running e2fsck on XFS produces an error, not a repair. │
└─────────────────────────────────────────────────────────┘

The fstab Fields

┌─────────────────────────────────────────────────────────┐
│  /etc/fstab line:                                       │
│                                                         │
│  UUID=1234  /data  ext4  defaults  0  2                │
│    │          │      │      │        │  │              │
│    │          │      │      │        │  └─ fsck order  │
│    │          │      │      │        └──── dump (0)    │
│    │          │      │      └───────────── mount opts  │
│    │          │      └──────────────────── filesystem   │
│    │          └─────────────────────────── mount point  │
│    └────────────────────────────────────── device (UUID)│
│                                                         │
│  Use UUID, not /dev/sdX: device names change.           │
│  Test with `mount -a` before rebooting.                 │
└─────────────────────────────────────────────────────────┘

Summary

Item	Value
VFS	Kernel layer that unifies filesystem access
ext4	General-purpose, shrinkable offline, `e2fsck`
XFS	High-throughput, grow-only, `xfs_repair`
Btrfs	Copy-on-write, snapshots, grow/shrink online
ext4 create	`mkfs.ext4`
XFS create	`mkfs.xfs`
Btrfs create	`mkfs.btrfs`
ext4 repair	`e2fsck -f`
XFS repair	`xfs_repair`
Btrfs repair	`btrfs check`
Persistent mount	`/etc/fstab` with UUID

Key takeaways:

The resize direction decides the filesystem. If shrinking is a requirement, XFS is excluded. ext4 shrinks offline; Btrfs shrinks online.
Snapshots are a Btrfs feature. ext4 and XFS do not provide native snapshots. If rollback is a requirement, the filesystem choice is Btrfs.
The repair tool is filesystem-specific. e2fsck, xfs_repair, and btrfs check are not interchangeable. fsck.xfs and fsck.btrfs are no-ops.
The VFS hides the differences. Applications see the same interface regardless of filesystem. Administrators still need to know the underlying behavior.
XFS is built for scale. Large filesystems, large files, and high concurrency are its strengths. Shrinking is not a feature it offers.
ext4 is the predictable default. It has a long history, a familiar toolset, and both grow and shrink support, at the cost of older design constraints.
Btrfs is the feature-rich option. Checksums, compression, snapshots, and flexible resize come with additional operational complexity.
/etc/fstab should use UUIDs. Device names can change across reboots; UUIDs identify the filesystem itself.
Special filesystems are not storage. tmpfs, proc, sysfs, and devtmpfs appear in mount output but are not partitioned or formatted with mkfs.
The distribution default is a starting point. SUSE defaults to Btrfs, Red Hat to XFS, Debian/Ubuntu to ext4. Know why the default was chosen, and when to override it.

Remember: A filesystem is not just a place to put files. It is a contract about what operations are possible: whether the volume can shrink, whether it can snapshot, how it recovers from a crash, and which tool repairs it when something goes wrong. ext4, XFS, and Btrfs each answer those questions differently, and none is universally correct. The LFCS candidate should be able to format all three, mount all three, repair all three, and explain in one sentence why a given workload would choose one over the others. The commands are the easy part; the reasoning behind the choice is what the storage domain tests.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!