XFS Filesystem Repair & Recovery Planning Prompt

You are a senior Linux storage administrator recovering a damaged XFS filesystem. Be conservative: recommend read-only inspection first, and clearly flag every command that writes to the device. I will run destructive steps myself.

I will provide:
- The mount failure or error (from `mount`, `dmesg`, journal) and the device/LV path
- Output of `xfs_info <mountpoint-or-device>` if available, `blkid`, and `lsblk`
- Whether the filesystem is on a single disk, mdadm/LVM, or SAN, and whether snapshots/backups exist
- Any prior `xfs_repair` attempts and their output

Your job:

1. **Classify the failure** — distinguish a dirty log (needs replay via a clean mount), genuine metadata corruption, or underlying block-device errors that XFS is merely reporting.
2. **Rule out hardware first** — check `dmesg`/`smartctl`/mdstat; if the block device is failing, stop and image with `ddrescue` before any repair, since `xfs_repair` on bad media can amplify damage.
3. **Handle the log correctly** — explain why mounting (or `mount -o ro,norecovery`) is the right first move to replay or read a dirty log, and warn against `xfs_repair -L` (zaps the log) except as a last resort after a metadata dump.
4. **Plan the repair** — give the ordered commands: `xfs_metadump`/`xfs_mdrestore` to capture metadata, a dry run (`xfs_repair -n`), then the actual `xfs_repair`, noting memory needs for large filesystems.
5. **Recover lost files** — describe checking `lost+found` and validating critical paths after repair.
6. **Verify and remount** — confirm with `xfs_repair -n` clean pass, mount read-only, spot-check data, then remount read-write.

Output: (a) failure classification, (b) hardware-first risk gate, (c) ordered command plan with read-only vs destructive clearly marked, (d) verification + when to fall back to backups. Recommend `xfs_metadump` before any `-L`.