xfs_repair taking a long time
I am having the same problem as the person in this thread:
Which is xfs_repair has been running for 16 hours on a 1 TB raid array. It gave the same errors as this thread, saying that it could not use any of the super blocks it found. The last email in the thread says:
-----------------------------------------
xfs-repair did find candidate secondary superblocks - it discarded them for some reason or another. If they were ok, all repair would have done is copied them to block zero and then continued.
I'm suggesting that you manually do this step, and then see if repair will run.
Quoted 3 lines
Before wrapping this up, if you could just clarify a couple things. If I look at the bytes at the beginning of each physical part of the LVM's, what am I looking for? "XFSB"?
yes.
Quoted 3 lines
If I do find that byte string, why
couldn'txfs_repairfind it when it did the scan and what do I do with it if I do find one?
As I said above, xfs-repair did find some, but rejected them for some (unknown) reason. if you find one, copy it over block zero of the partition, and see if repair will run. Like I said, though, you'll probably want to back up th partition first, or at least run repair in no-modify mode.
--------------------------------------
The poster, Dave Chinner, says to manually copy the superblock to the right place, but not how to do it. I am familiar with dd, but would like to know the exact command or steps to take to replace the primary superblock manually with a secondary superblock.
Ashley
(I sent this earlier but I haven't seen it come over the list yet, so I'll send it again. Please forgive the duplicate.)
I have run xfs_metadump on the array and here is the output:
root@slax:~# xfs_metadump -V xfs_metadump version 2.9.7 root@slax:~# xfs_metadump /dev/sda /root xfs_metadump: unexpected XFS SB magic number 0x00000000 xfs_metadump: read failed: Invalid argument xfs_metadump: data size check failed cache_node_purge: refcount was 1, not zero (node=0x80e2670) xfs_metadump: cannot read root inode (22) xfs_metadump: bad superblock magic number 0, giving up
It looks like the superblock got corrupted, and xfs_repair can't find another one to fix it.
Any ideas on how to get it back?
Ashley
Quoted 47 lines · Ash
I am having the same problem as the person in this thread:
Which is
xfs_repairhas been running for 16 hours on a 1 TB raid array. It gave the same errors as this thread, saying that it could not use any of the super blocks it found. The last email in the thread says:-----------------------------------------
xfs-repair did find candidate secondary superblocks - it discarded them for some reason or another. If they were ok, all repair would have done is copied them to block zero and then continued.
I'm suggesting that you manually do this step, and then see if repair will run.
Quoted 1 line
Before wrapping this up, if you could just clarify a couple
things. If I
Quoted 2 lines
look at the bytes at the beginning of each physical part of the LVM's, what am I looking for? "XFSB"?
yes.
Quoted 2 lines
If I do find that byte string, why
couldn'txfs_repairfind it when it did the scan and what do I dowith it
Quoted 1 line
if I do find one?
As I said above, xfs-repair did find some, but rejected them for some (unknown) reason. if you find one, copy it over block zero of the partition, and see if repair will run. Like I said, though, you'll probably want to back up th partition first, or at least run repair in no-modify mode.
--------------------------------------
The poster, Dave Chinner, says to manually copy the superblock to the right place, but not how to do it. I am familiar with dd, but would like to know the exact command or steps to take to replace the primary superblock manually with a secondary superblock.
Ashley
(I sent this earlier but I haven't seen it come over the list yet, so I'll send it again. Please forgive the duplicate.)