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.
- Out of nowhere, any file in
/homecould not be saved/edited, etc. or any directory listed.
xfs_do_force_shutdown calledaround a few other xfs messages.
xfs_repairfailed in Phase 1 with
superblock read failedfollowed by
fatal error -- Input/output error
- The rest of my disk was operating flawlessly (including
/, i.e. only
/homewas not working).
- Attempting to
mountwould lead to
superblock cannot be found(or analogous) error, but no hint as to what to do next.
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
- 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/sdaif there is a relatively recent long test (as there was in my case).
- Examine the test with either:
smartctl -l selftest /dev/sdaor
smartctl -a /dev/sda(the latter displays everything, but the information you need is almost at the very end).
- 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).
- 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*
- 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.
xfs_repair /dev/sda(without the
-Lflag). This will likely report that you should attempt to mount the filesystem because of the journal log errors.
- Attempt to mount that system. In my case, that failed, so I had to run
xfs_repair -L /dev/sdawhich deletes the journal log (which may result in data being deleted).
- 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
xfs_checkhas been made obsolete in favor of
- 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 xfsprogsonly to realize that, this being Debian, their "stable" packages are literally years behind. Long story short,
xfs_repair /dev/sdajust 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.