Filesystems

A filesystem maps filenames and directories onto disk blocks. When you write a file, the filesystem decides which blocks to use, writes your data there, and records the mapping in its metadata structures. When you read the file back, it looks up the mapping and reassembles the data.

The core structures:

• Superblock — the master record: filesystem type, total size, block size, number of inodes, pointers to the block group descriptors. If the superblock is corrupted, the filesystem cannot be mounted. ext4 keeps backup superblock copies in several block groups for exactly this reason.
• Block groups — ext4 divides the partition into groups of blocks. Each group has its own copy of the block bitmap (which blocks are free), inode bitmap, and inode table. This locality means that reading a file usually hits one block group, not random disk locations.
• Inode (index node) — a fixed-size metadata record (256 bytes in ext4) that stores everything about a file except its name: owner UID/GID, permissions, timestamps (atime/mtime/ctime), size, and pointers to the data blocks.
• Directory entry (dentry) — the mapping from a filename to an inode number. A directory is itself a file whose data is a list of (filename, inode_number) pairs.

# See filesystem metadata on a mounted partition
stat /etc/hostname
# File: /etc/hostname
#   Size: 10        Blocks: 8          IO Block: 4096   regular file
# Device: 8,3         Inode: 2621554     Links: 1
# Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
# Access: 2024-06-20 09:12:01
# Modify: 2024-01-15 14:22:03
# Change: 2024-01-15 14:22:03

# The inode number is 2621554 — that is the filesystem's internal ID for this file
# The filename '/etc/hostname' is just a dentry pointing to this inode

ext4 is the default Linux filesystem and the safe choice for most workloads. It has been the default on Debian/Ubuntu since 2010, has excellent fsck tooling, and handles power failures gracefully via journaling.

# Create an ext4 filesystem on a partition
sudo mkfs.ext4 /dev/sda3
# mke2fs 1.47.0 (5-Feb-2023)
# Creating filesystem with 130678784 4k blocks and 32669696 inodes
# Filesystem UUID: e5f6a7b8-c9d0-1234-5678-abcdef012345
# Superblock backups stored on blocks: 32768, 98304, 163840, ...
# Allocating group tables: done
# Writing inode tables: done
# Creating journal (131072 blocks): done
# Writing superblocks and filesystem accounting information: done

# Custom inode count (useful for directories-heavy workloads like mail servers)
sudo mkfs.ext4 -N 8000000 /dev/sda3   # 8 million inodes instead of default

# Custom block size (4096 is the default; match your storage's native sector size)
sudo mkfs.ext4 -b 4096 /dev/sda3

# Add a label (useful for fstab and identification)
sudo mkfs.ext4 -L data /dev/sda3

# Inspect filesystem metadata after creation
sudo tune2fs -l /dev/sda3 | grep -E 'Inode count|Block count|Block size|Journal'
# Inode count:              32669696
# Block count:              130678784
# Block size:               4096
# Journal inode:            8

Journaling is what makes ext4 reliable. Before writing to the filesystem data structures, it writes a record to the journal (a dedicated area on disk). If the system crashes mid-write, fsck replays the journal to restore consistency instead of scanning the entire disk.

xfs and btrfs cover workloads where ext4 is not the best fit.

# Create xfs (large-file, high-throughput workloads: databases, video, streaming)
sudo mkfs.xfs /dev/sdb1
# meta-data=/dev/sdb1              isize=512    agcount=4, agsize=65536 blks
# data     =                       bsize=4096   blocks=262144, imaxpct=25
# naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
# log      =internal log           bsize=4096   blocks=16384, version=2
# realtime =none

# Create btrfs (snapshots, subvolumes, transparent compression, checksums)
sudo mkfs.btrfs /dev/sdc1
# btrfs-progs v6.1
# Label:              (none)
# UUID:               9f8e7d6c-...
# Nodesize:           16384
# Sectorsize:         4096
# Features:           skinny-metadata, no-holes

Key differences:

btrfs write performance can lag ext4/xfs on spinning disks under write-heavy loads due to copy-on-write overhead. On SSDs the difference is small.

Inodes are a fixed pool. You can run out of them while the disk still has space. This is one of the most confusing errors an operator encounters.

# Check inode usage — THIS IS THE CHECK PEOPLE FORGET
df -i
# Filesystem      Inodes  IUsed   IFree IUse% Mounted on
# /dev/sda3     32669696 3100000 29569696    9% /
# /dev/sda2       131072   78000   53072   60% /boot   <- getting full
# /var/spool/mail  524288  524287       1  100% /var/mail  <- FULL!

# What happens when inodes are exhausted:
# touch /var/mail/newfile
# touch: cannot touch '/var/mail/newfile': No space left on device
# BUT:
df -h /var/mail
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sdc1        20G  8.1G 11.9G  41% /var/mail   <- 41% free! But no inodes left.

# Count files in a suspicious directory
find /var/spool/postfix/deferred -type f | wc -l
# 524281   <- mail server queued 524281 emails — each consumed one inode

# How many inodes were allocated at mkfs time?
sudo tune2fs -l /dev/sdc1 | grep 'Inode count'
# Inode count: 524288   <- mkfs.ext4 calculated based on total size, not workload

The fix is to either clean up the files consuming inodes, or reformat with a higher inode count (mkfs.ext4 -N <count>). You cannot add inodes to an existing ext4 filesystem without reformatting. xfs and btrfs allocate inodes dynamically and do not have this problem — they only run out of inodes when they run out of disk space.

The superblock is the filesystem’s master record — and knowing where backups are saves you.

# Find backup superblock locations (useful when primary is corrupted)
sudo mke2fs -n /dev/sda3   # -n = dry run, shows what mkfs would do
# Superblock backups stored on blocks: 32768, 98304, 163840, 229376, ...

# If the primary superblock (block 0) is damaged:
sudo fsck.ext4 -b 32768 /dev/sda3   # use the backup at block 32768
# e2fsck 1.47.0 (using backup superblock at block 32768)
# /dev/sda3: recovering journal
# /dev/sda3: clean, 3100000/32669696 files, 24500000/130678784 blocks

# Check and repair a filesystem (must be unmounted first)
sudo umount /dev/sda3
sudo fsck.ext4 -f /dev/sda3   # -f = force check even if marked clean

# For xfs (xfs uses a different approach — log replay rather than fsck scan)
sudo xfs_repair /dev/sdb1   # must be unmounted

# For btrfs
sudo btrfs check /dev/sdc1  # read-only check; use --repair with extreme caution

Never run fsck on a mounted filesystem. On ext4, the kernel marks the filesystem “clean” at unmount and “dirty” at mount. At boot, systemd runs fsck on partitions marked as dirty (pass 1 or 2 in /etc/fstab). The superblock’s Last mount time and Last checked fields tell you when the filesystem was last verified.