Keeping filesystems intact

Space, and the second thing that runs out

df reports free space per mounted filesystem — df -h in human units, df -i for inodes. That second one matters: a filesystem can be nowhere near full in bytes and still refuse to create a file, because every file needs an inode and the count was fixed when the filesystem was made. Millions of tiny files is how you get there, and df alone will not show it.

du reports usage by directory, walking the tree — du -sh DIR for one total, du -h --max-depth=1 to find which subdirectory is the problem. df and du can legitimately disagree: a deleted file still held open by a running process is gone from du's tree and still occupying space df counts, which is resolved by restarting whatever holds it.

Checking and repairing

fsck is the front end that dispatches to a filesystem-specific checker: e2fsck for the ext family, xfs_repair for XFS. The rule that matters more than any flag is that a filesystem must be UNMOUNTED, or mounted read-only, before it is checked — running a repair on a live filesystem corrupts it. Checks also run automatically at boot, driven by the mount count and interval in the superblock.

A journal is what makes most of that unnecessary. ext3, ext4 and XFS record what they are about to do before they do it, so after a power cut the filesystem replays or discards the incomplete records rather than scanning every inode. ext2 has no journal, which is precisely why an ext2 filesystem takes so long to check after an unclean shutdown.

tune2fs adjusts ext filesystem parameters after creation — the label, the reserved-blocks percentage, the check interval — and tune2fs -l prints the superblock. dumpe2fs prints far more detail. badblocks scans for physically bad sectors, and is the layer below all of this.

XFS answers with a family of separate programs rather than flags on one, and what separates them is which may run on a MOUNTED filesystem. xfs_repair checks and repairs, and demands the filesystem be unmounted, because it rewrites metadata the kernel also believes it owns. xfs_fsr reorganises the data of a filesystem that is mounted and in use — the defragmenter, and it is safe there precisely because it moves file contents through ordinary filesystem calls rather than going behind the kernel's back. xfs_db inspects metadata, xfs_info reports geometry and xfs_admin changes the label and UUID. The generalisation is worth carrying past XFS: a repair tool wants the filesystem offline, a reorganiser does not.