Mounting XFS RAID-1 Disk Partition That Needs Repair.

Home » CentOS » Mounting XFS RAID-1 Disk Partition That Needs Repair.
CentOS 6 Comments

I’m attempting to extract data from a HD that has a bunch of linux-raid partitions, including one large one with data I need to save off the disk.

I actually have two drives like that (both not from the same RAID pair), and one of them I was successful in creating a MD device so I could mount it RO and copy off a ton of data.

the second one fails to mount, saying the XFS filesystem is corrupted. Attempting to run XFS_repair I get a message that the filesystem is XFS-1
and I need an older version of XFS tools to do it.

I’m running CentOS-7 with whatever version of XFS tools comes with it, according to ‘yum list installed’ it appears to be xfsprogs 4.5.0-22.el7.

I don’t particularly want to install another, older, version of xfsprogs on this system. can anyone suggest any other way to gain access to this disk partition?

Thanks in advance!

Fred

6 thoughts on - Mounting XFS RAID-1 Disk Partition That Needs Repair.

  • You could try downloading an ISO of knoppix, and boot from that with the drive installed, and use the xfs_repair tools from there without having to install other tools on the drive in question.

  • Hi,

    Are you sure the filesystem is really corrupt? Maybe it’s only your kernel which doesn’t understand the old XFS version?

    To use older xfs_repair, you can just download an older version like xfsprogs-2.9.4-1.el4.CentOS.x86_64.rpm, extract it to a directory and call the xfs_repair binary from the package.

    I’m not sure whether you need a matching xfs kernel module to run xfs_repair successfully.

    Regards, Simon

  • haven’t tried the suggestions yet, but here is some diagnostics on what happens when I attempt to mount it:
    upon running *mdadm –assemble /dev/md40 /mnt/dvd –run*, info from
    /var/log/messages):
    (note that /mnt/dvd is just an empty mount point that exists, used here for convenience).

    Nov 24 12:21:42 fcshome kernel: md: md40 stopped. Nov 24 12:21:42 fcshome kernel: md/raid1:md40: active with 1 out of 2
    mirrors Nov 24 12:21:42 fcshome kernel: md40: detected capacity change from 0 to
    996887429120

    output from doing:
    sudo mount /dev/md40 /mnt/dvd mount: mount /dev/md40 on /mnt/dvd failed: Structure needs cleaning

    corresponding items from /var/log/messages:
    Nov 24 12:22:55 fcshome kernel: XFS (md40): Superblock earlier than Version
    5 has XFS_[PQ]UOTA_{ENFD|CHKD} bits. Nov 24 12:22:55 fcshome kernel: XFS (md40): Metadata corruption detected at xfs_sb_read_verify+0x122/0x160 [xfs], xfs_sb block 0xff ffffffffffffff Nov 24 12:22:55 fcshome kernel: XFS (md40): Unmount and run xfs_repair Nov 24 12:22:55 fcshome kernel: XFS (md40): First 128 bytes of corrupted metadata buffer:
    Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0000: 58 46 53 42 00 00 10 00
    00 00 00 00 0e 81 b1 e0 XFSB………… Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0010: 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 ……………. Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0020: d2 22 a7 30 dd 88 48 8b bd bb 9c 8b 2a 22 72 cc .”.0..H…..*”r. Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0030: 00 00 00 00 08 00 00 04
    00 00 00 00 00 00 00 80 ……………. Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0040: 00 00 00 00 00 00 00 81
    00 00 00 00 00 00 00 82 ……………. Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0050: 00 00 00 01 00 74 0d 8f
    00 00 00 20 00 00 00 00 …..t….. …. Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0060: 00 00 80 00 30 c4 02 00
    01 00 00 10 00 00 00 00 ….0……….. Nov 24 12:22:55 fcshome kernel: ffff8e0c8f4e0070: 00 00 00 00 00 00 00 00
    0c 09 08 04 17 00 00 19 ……………. Nov 24 12:22:55 fcshome kernel: XFS (md40): SB validate failed with error
    -117.

    running xfs_repair give:
    sudo xfs_repair /dev/md40
    Phase 1 – find and verify superblock… xfs_repair: V1 inodes unsupported. Please try an older xfsprogs.

    before proceeding with other experiments, I decided to use dd to create an image file on my local disk of that partition so I could mess with it with less chance of trashing the on-disk partition. when attempting to use it, I
    get:

    sudo mdadm –assemble /dev/md41 ./part4.img –run mdadm: ./part4.img is not a block device. mdadm: ./part4.img has no superblock – assembly aborted

    So, I thought maybe the image had somehow become corrupted, so I did:

    sudo md5sum /dev/sdd4
    bd7cac3c886e7b3110e28100e119bb82 /dev/sdd4

    and

    md5sum part4.img bd7cac3c886e7b3110e28100e119bb82 part4.img

    which shows the partition and its disk image to be identical.

    Why shouldn’t a dd image of a partition work just as well (for my purposes)
    as the actual disk partition? I’ve certainly done this before with EXTn and NTFS filesystems, is XFS somehow different in this regard?

    Do any of you know what I’m doing wrong here?

    Thanks in advance!

    Fred

  • I’m not sure but I think you are making it too complicated.

    If the partition is from a software RAID 1, then you should be able to use it directly without building an mdadm array.

    That said, it depends on the metadata type IIRC. If metadata is in the beginning of the partition, then you have to remove it by doing a dd to a file and skipping the metadata in the beginning of the partition.

    md raid metadata locations:
    0.9 At the end of the device
    1.0 At the end of the device
    1.1 At the beginning of the device
    1.2 4K from the beginning of the device

    So with metadata versions 0.9 0r 1.0, you could directly use the md partition like a normal partition, only some bytes in the end are not used by the filesystem.

    Regards, Simon