How to recover XFS file system with "superblock read failed"

The answers above did not help me when I had this issue today (about 9.5 hours ago now). I'll present here the solution that worked for me, along with the reasons why the previous answer did not help.

Symptoms

1. Out of nowhere, any file in /home could not be saved/edited, etc. or any directory listed.
2. dmesg showed somewhere xfs_do_force_shutdown called around a few other xfs messages.
3. xfs_repair failed in Phase 1 with superblock read failed followed by fatal error -- Input/output error
4. The rest of my disk was operating flawlessly (including /, i.e. only /home was not working).
5. Attempting to mount would lead to superblock cannot be found (or analogous) error, but no hint as to what to do next.

Solution

The solution is based on this post Nigel Smith, the main author of XFS (if I understand correctly). I'll repost the steps here in case the previous link becomes obsolete. All the following operations must be ran as root (evidently).

1. Run a long self test of the drive: smartctl -t long /dev/sda. This may take a while. You can also run a short test with smartctl -t short /dev/sda if there is a relatively recent long test (as there was in my case).
2. Examine the test with either: smartctl -l selftest /dev/sda or smartctl -a /dev/sda (the latter displays everything, but the information you need is almost at the very end).
3. The last column of the test report is called LBA_of_first_error. This is the position of the first error on the disk. From the latest test (which will be numbered "#1" and sit at the top of the list), grab the number displayed and divide this by eight and truncating to an integer value (cf. original post as to why).
4. Then, you will zero-out this specific block. This will lead to the specific file at this position to be corrupted. (But if you have exhausted every other method, a few corrupted files isn't that big a deal.). Do to so, run the following command: # dd if=/dev/zero of=/dev/sda conv=sync bs=4096 count=1 seek=*NUMBER_COMPUTED_EARLIER*
5. Perform a short test and wait a minute or two for the result. Repeat this until the short test does not display any error. Or, you can check the approximate number of erroneous block with smartctl -A /dev/hda | egrep 'Reallocated|Pending|Uncorrectable' In my case, I repeated steps 1 through 4 until I was down to 24 errors.
6. Run xfs_repair /dev/sda (without the -L flag). This will likely report that you should attempt to mount the filesystem because of the journal log errors.
7. Attempt to mount that system. In my case, that failed, so I had to run xfs_repair -L /dev/sda which deletes the journal log (which may result in data being deleted).
8. Mount your file system and do a recent backup!

Why the above solutions don't work anymore

• The initial post is several years old. In the meantime, there have been enough changes to XFS for it be considered stable enough by the SuSE team to use as the primary FS for /home.
• xfs_check has been made obsolete in favor of xfs_repair -n.
• The Debian solution was a horrible hassle and waste of time. As of now, Debian does not support UEFI boot, and that information is not on their download page nor on their main FAQ page (it's on their Wiki). So in order to boot with that, you need to disable UEFI Secureboot in your BIOS and then boot on the key. Afterwards, you'll note that there no xfs tools installed by default. So you'll do apt-get install xfsprogs only to realize that, this being Debian, their "stable" packages are literally years behind. Long story short, xfs_repair /dev/sda just hung forever. The process could not be killed (even with a sigterm).
• UFS Explorer is paid-for software.
• photorec only supports specific file types (say bye-bye to your GPG keys) and restores all files with arbitrary names all in one folder. Good luck going through all that and finding relevant information.

After the XFS replay error, try to MOUNT the partition again, as per the error message.

If all gets too messy, I highly recommend downloading UFS Explorer to help with deep file recovery from another system.