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

9

I have a disk from a Buffalo LinkStation that has an XFS partition on it that I cannot mount.

Plugging the disk into an SATA->USB caddy on an Ubuntu box. I get the following:

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63      594404      297171   83  Linux
/dev/sdb2          594405     1590434      498015   83  Linux
/dev/sdb4         1590435   976768064   487588815    5  Extended
/dev/sdb5         1590498     1863539      136521   82  Linux swap / Solaris
/dev/sdb6         1863603   976494959   487315678+  83  Linux

The problem partition is /dev/sdb6.

$ sudo xfs_check /dev/sdb6
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

So trying the xfs_repair -L option gets me to the situation I can't get beyond:

$ sudo xfs_repair -L /dev/sdb6
Phase 1 - find and verify superblock...
superblock read failed, offset 382252089344, size 131072, ag 89, rval -1

fatal error -- Input/output error

Using photorec I have been able to pull some files off that partition, so the data is there and the disk is physically working. However, there is a problem with the superblocks.

How would I recover this partition?

filesystems
data-recovery
xfs
asked on Server Fault Jan 15, 2013 by Kieran • edited Jan 15, 2013 by Kieran

4 Answers

5

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.
answered on Server Fault Feb 25, 2017 by ChrisR • edited May 19, 2019 by Mikher
3

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.

answered on Server Fault Jan 15, 2013 by ewwhite
1

I have XFS partition on "sda6". On Lubuntu it's corrputed, won't fix and won't mount XFS partition on 13.10. When booting Lubuntu it's says that should be fix and trying on boot to fix XFS filesystem. When I went on first installation Lubuntu, on partition it's says Unknown.

Lubuntu didn't fixed. Using command xfs_check for me didn't solved.

I finally solved back to Debian 7 and reinstall. It's detected all filesystems and normally mounted XFS partition.

I read many users for XFS fileystems, so I think it's problem on changes on kernel versions, because Debian 7 use version 3.2 and mounts XFS normally without errors, but on Ubuntu with latest kernel 3.11 won't solved XFS filesystem.

I tried with CentOS 6.5 but CentOS follow up with RedHat and with old "stable" kernel. It won't detected XFS automatically.

Finally I've on Debian 7 backups all data on XFS partition and recreate partitions to EXT4.


Due to RedHat won't fix XFS reading partition and some problems with XFS (google it how many users didn't solved XFS reading partitions) I've generally opt with Debian to backup and change to new compatible with kernel 3.11 to EXT4/btrfs... filesystems.

Hope this someone helps.

answered on Server Fault Dec 15, 2013 by Marin Sagovac
0

I fixed my XFS partition using a new downloaded Debian 8.7.1 over a real server just put the disk over this system and it repairs automatic . Centos 5 and 6 can not repaired it

answered on Server Fault Mar 14, 2017 by Kan

User contributions licensed under CC BY-SA 3.0