I forgot to mention, that i actually have an metadump. But it is only written
till xfs_db hangs.
It's filesize is 399M, is that enough to work with that?
* mill / in-medias-res <mill@xxxxxxxxxxxxxxxxx> [091104 16:20]:
> Hello XFS-Community,
> 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
> 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
> Best Regards,
> Maximilian Mill