Rocky 9: judging and repairing a damaged XFS

Test scope

Reproduced in a Rocky Linux 9.8 privileged container (host kernel 5.14.0-687.54.1.el9_8) with a 512 MB loop disk: a healthy filesystem, repair refused while mounted, a -n dry run after unmounting, zeroing the first four bytes to fake a bad superblock, xfs_repair recovery, then remount and read. Log: plans/content-expansion/evidence/logs/rocky-xfs-repair.log.

Repairing a production volume (backups, snapshots, downtime) is out of scope; this page covers command behaviour and the order of decisions.

Decision order: can it be repaired at all?

Three questions, in this order:

1. Is it still mounted? If so, it cannot be repaired;
2. What does -n report? It separates a minor issue from a superblock repair;
3. Do you have a backup or snapshot? If not, take one before touching anything.

While mounted, repair is refused outright

sudo xfs_repair /dev/loop0

xfs_repair: /dev/loop0 contains a mounted and writable filesystem

fatal error -- couldn't initialize XFS library

The kernel still holds cache and journal state for that filesystem; repairing under a live mount only produces messier metadata. Stop the workload and unmount, or repair a snapshot on another host.

Dry run: -n reads but never writes

sudo umount /mnt/x
sudo xfs_repair -n /dev/loop0

Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

The value of a dry run is getting the problem list first; archive it in production before deciding on a real repair.

What a bad superblock looks like

sudo dd if=/dev/zero of=/dev/loop0 bs=4 count=1 conv=notrunc
sudo mount /dev/loop0 /mnt/x

mount: /mnt/x: wrong fs type, bad option, bad superblock on /dev/loop0, ...

XFS magic is the first four bytes, XFSB; zeroed, the kernel no longer recognises a filesystem and mount reports bad superblock.

Repair: recover from a backup superblock

sudo xfs_repair /dev/loop0

Phase 7 - verify and correct link counts...
Note - stripe unit (0) and width (0) were copied from a backup superblock.
done

XFS keeps superblock copies across the disk and repairs the primary from a backup; the Note says geometry was copied from the backup, so RAID volumes should correct stripe settings as suggested.

Always mount and verify afterwards

sudo mount /dev/loop0 /mnt/x
cat /mnt/x/a.txt

hello

Success means it mounts and key files read back; done alone does not prove the data is intact.

Common traps

• Repairing under a live mount: refused; unmount first or use a snapshot;
• Treating -n as a repair: it writes nothing;
• Ignoring the stripe note: geometry restored from a backup may lose RAID settings and hurt performance.

Practice: reproduce a bad-superblock repair

sudo dnf install -y xfsprogs
truncate -s 512M /var/tmp/x.img
L=$(sudo losetup -f --show /var/tmp/x.img)
sudo mkfs.xfs -q "$L"
sudo mkdir -p /mnt/x && sudo mount "$L" /mnt/x
echo hello | sudo tee /mnt/x/a.txt >/dev/null && sync
sudo umount /mnt/x
sudo dd if=/dev/zero of="$L" bs=4 count=1 conv=notrunc
sudo xfs_repair "$L" | tail -3
sudo mount "$L" /mnt/x && cat /mnt/x/a.txt

Checks:

1. mount reports bad superblock before the repair
2. xfs_repair output ends with done
3. After repair, cat /mnt/x/a.txt prints hello
4. xfs_repair -n "$L" prints No modify flag set

FAQ

常见问题

Why is repair refused while mounted?

Repair changes metadata while the mounted kernel still holds cached state and journal assumptions, producing an inconsistent result. Unmount first, or repair a snapshot on another host.

How is `-n` different from a real repair?

`-n` scans and reports without writing; a real repair writes changes. In production, dry-run and archive the output before deciding.

Is the data guaranteed after a repair?

No. Repair restores a usable filesystem structure; data in damaged areas may end up as orphaned files in lost+found. Mount and read key data afterwards, and restore from backup when needed.

Next steps

• Growing storage: LVM growth
• Post-install checks: 7 checks after install
• Log rotation: logrotate in practice