> Hmm interesting.
> Can you go into xfs_db and print out the bad inode? send it to us?
> I'm guessing the extents are corrupted somehow.
Did you mean "xfs_db -x -c 'blockget inode 3256930831' /dev/sdc2" ?
xfs_db consumes 99% of CPU and Virt 2510m RES 194m of RAM.
How long should i wait?
> 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.
If i can't get that block i will try with deleting it, Thanks!
>> 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
>> 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
>> xfs mailing list