xfs_repair breaks; xfs_metadump hangs

mill / in-medias-res mill at in-medias-res.com
Mon Nov 9 03:19:15 CST 2009


> 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.
> http://jijo.free.net.ph/19
If i can't get that block i will try with deleting it, Thanks!

Best regards,
Maximilian Mill
>> 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 position:
>> 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?
>>
>> Versions:
>> 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 3256930831.
>>
>> Best Regards,
>> Maximilian Mill
>>
>> _______________________________________________
>> xfs mailing list
>> xfs at oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>>
>>   
>
>




More information about the xfs mailing list