mill / in-medias-res wrote:
i have some real trouble with restoring/repairing my two XFS Partion's. These
Partion's are on a RAID-5 Array which "was broken". The first xfs_repair run
on /dev/sdc1 did restore 80 GB from ca. 300-400 GB. The Problem was that 99,9%
of the million files are in lost+found.
Because i was more interested in restoring /dev/sdc2, i did forget about sdc1
and run xfs_repair on the other Partion:
cmd: xfs_repair -t 1 -P /dev/sdc2
corrupt inode 3256930831 ((a)extents = 1). This is a bug.
Please capture the filesystem metadata with xfs_metadump and
report it to xfs@xxxxxxxxxxxx
cache_node_purge: refcount was 1, not zero (node=0x377d0008)
fatal error -- couldn't map inode 3256930831, err = 117
Can you go into xfs_db and print out the bad inode? send it to us?
I'm guessing the extents are corrupted somehow.
One option to then flag the inode as deleted which will cause repair to
toss is hopefully clean up the mess.
Here is a write up how to do that.
time: 67,27s user 10,09s system 10% cpu 12:05,31 total
I tried to run xfs_metadump serveral times and it hangs everytime on this
xfs_metadump -g /dev/sdc2 metadump-sdc2-2
Copied 1411840 of 4835520 inodes (0 of 3 AGs)
It runs till 2 days on the same inode and xfs_db consumes 99% of CPU.
Should i wait here?
dpkg -l |grep xfs
ii xfsdump 3.0.2~bpo50+1 Administrative utilities for the XFS filesys
ii xfsprogs 3.0.4~bpo50+1 Utilities for managing the XFS filesystem
Distribution: Debian lenny with xfsprogs, xfsdump backport from unstable.
The xfs_repair with stock Debian Lenny version also does crash at inode
xfs mailing list