Filesystems & mounts

ext4, xfs, mount options, and repair.

On top of a partition or logical volume sits a filesystem — the structure that turns raw blocks into files and directories. On Linux the two you meet most are ext4 (the long-time general-purpose default: reliable, well-understood) and xfs (high-performance, especially for large files and parallel IO, the default on RHEL). Both are journaling filesystems, meaning they log pending changes so a crash leaves the filesystem recoverable rather than corrupt. For most workloads either is fine; the differences matter at the extremes of size and concurrency.

$ lsblk -f                       # block devices with their filesystems + mount points
NAME        FSTYPE  MOUNTPOINT
sda
└─sda1      ext4    /
sdb
└─data--vg-app xfs   /srv/app
$ sudo mkfs.ext4 /dev/data-vg/logs      # create an ext4 filesystem
$ df -Th                          # -T adds the filesystem TYPE column

Mounting and /etc/fstab

A filesystem is attached to the directory tree by mounting it. mount does it now; /etc/fstab makes it persistent across reboots, listing each filesystem, where to mount it, its type, and options. The right way to identify a device in fstab is by UUID, not /dev/sdb1 — because kernel device names can change between boots (add a disk and yesterday’s sdb becomes sdc), while the UUID is stable. Getting fstab right is what makes storage survive a reboot; getting it wrong can stop the boot.

# <device>                               <mount>    <type> <options>       <dump> <pass>
UUID=8f3a-...                             /srv/app   xfs    defaults,noatime 0      2
UUID=b1c2-...                             /var/log   ext4   defaults,nofail  0      2
#                                                                          └ nofail: do not
#   block boot if this device is missing.   noatime: skip access-time writes (a perf win)
# find a device’s UUID:  blkid /dev/data-vg/app

Checking and repairing

When a filesystem is damaged (a bad shutdown, hardware trouble), fsck checks and repairs it — but only safely on an UNMOUNTED filesystem, so you run it from rescue mode or on a secondary disk, never on a live mounted root. The journal usually means you rarely need fsck, but knowing it exists and that it must run unmounted is part of recovery. For live insight, tools like df (space), du (usage), and lsblk (layout) are your everyday view; fsck is the repair tool of last resort.

$ sudo umount /dev/data-vg/logs         # fsck needs it UNMOUNTED
$ sudo fsck -y /dev/data-vg/logs         # check and auto-repair
# for the root filesystem you cannot unmount: schedule a check at next boot
$ sudo touch /forcefsck    # (or fsck.mode=force on the kernel cmdline) then reboot into rescue