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?

Kieran
  • 193
  • 1
  • 1
  • 6
  • Thanks for clear question with steps. I came here for an answer and found it in your question itself `sudo xfs_repair -L ` :) – kAmol Nov 07 '20 at 12:51

5 Answers5

6

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.
Mikher
  • 3
  • 2
ChrisR
  • 161
  • 1
  • 4
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.

ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • Thanks for the quick reply. Mounting again after the failed. I just realised I pasted in the wrong command here...I did do the -L option on xfs_repair. However, trying to mount again still doesn't work. – Kieran Jan 15 '13 at 23:03
  • UFS EXPLORER - http://www.ufsexplorer.com/ – ewwhite Jan 15 '13 at 23:09
  • 1
    After trying a few free linux tools, nothing beat UFS Explorer. It may be £40, but it worked. Thanks. – Kieran Jan 18 '13 at 16:50
1

I recently had a big issue with a XFS 3To fs. Unable to mount, no superblock. xfs_repair didn’t found any relevant piece of a superblock. It’s a production machine, uptime 600 days, and i never used it before.

Tried a restore (2 days needed), nothing better.

Finaly, as i was about to tell to our client that all was lost, i tried a fsck. Clean Volume. It happens the fstab’s fstype was wrong, it was an ext4. All the other fs are in xfs but that one is in ext4.

xfs_repair could tell when the fs looks like an ext4 ...

Patrick BUNINO
  • 11
  • 1
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.

Marin Sagovac
  • 144
  • 4
  • 1
    I fixed my XFS partition from a Buffalo router (like Kieran plroblem) using a new downloaded Debian 8.6 with kernel 3.16.0-4-amd64 installed on a VirtualBox virtual machine ;-) – NetVicious Nov 19 '16 at 01:16
  • @NetVicious can you specify which command you ran? On a Debian 8.6 jessie Live USB I currently have xfs_repair hanging at the start. When in rescue on my OpenSuSE (my original distro), it does not hang, but it does display a "can't read superblock" error. – ChrisR Feb 24 '17 at 23:35
  • I used the fstransform command of linux. But I discovered VirtualBox USB 2.0 speed it's around 1MB/second, and my transformation lasted for more than 6 days. It has 2 stages, one for moving the data and other to transform it to the new filesystem format. So I suggest you to install it in a real partition without virtualization to use full USB speed. – NetVicious Feb 27 '17 at 09:52
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

Kan
  • 1