Re: xfs_repair on a 1.5 TiB image has been hanging for about an hour, now

[Eric Sandeen <sandeen@sandeen.net>]

Richard Hartmann wrote:
> Hi all,
> 
> one of our RAIDs recovered into an inconsistant state and I need to get
> back what data I can.
> 
> All steps taken happened and will continue to happen under Linux with
> either Debian and/or grml.
> 
> The XFS file system that can not be mounted is in a partition which is
> 1.5 TiB in size.
> I put an additional 2 TiB drive and used dd_rescue to copy over what the
> RAID presents as one large block device.
> 
> I then ran kpartx on the image to create the appropriate devices in
> /dev/mapper.
> 
> As the metadata was corrupt, I ran xfs_metadump -g and -go to have a
> personal backup and one I could give out if needed.
> 
> I then ran xfs_repair -L /dev/mapper/loop1p3 which has not been making
> any progress for the last hour.
> I don't see much load in ways of CPU or i/o, yet there is literally no
> progress at all. I am hanging at:
> 
> 
> no . entry for directory 39756
> no .. entry for directory 39756
> problem with directory contents in inode 39756
> cleared inode 39756
> data fork in ino 39771 claims free block 8391321
> bad directory block magic # 0x58443242 in block 0 for directory inode 39771
> corrupt block 0 in directory inode 39771
>         will junk block
> no . entry for directory 39771
> no .. entry for directory 39771
> problem with directory contents in inode 39771
> cleared inode 39771
> data fork in ino 39774 claims free block 44122
> data fork in ino 39774 claims free block 8432730
> bad directory block magic # 0x1f1f1f1f in block 0 for directory inode 39774
> corrupt block 0 in directory inode 39774
>         will junk block
> no . entry for directory 39774
> no .. entry for directory 39774
> problem with directory contents in inode 39774
> cleared inode 39774
> multiple . entries in directory inode 39816: clearing entry
> multiple .. entries in directory inode 39816: clearing entry
> bad directory block magic # 0x58443244 in block 0 for directory inode 39840
> corrupt block 0 in directory inode 39840
>         will junk block
> no . entry for directory 39840
> no .. entry for directory 39840
> problem with directory contents in inode 39840
> cleared inode 39840
> bad . entry in directory inode 39909, was 45188: correcting
> data fork in ino 40102 claims free block 8400946
> ab3e1b90: Badness in key lookup (length)
> bp=(bno 258176, len 8192 bytes) key=(bno 258176, len 4096 bytes)
> ab3e1b90: Badness in key lookup (length)
> bp=(bno 258224, len 8192 bytes) key=(bno 258224, len 4096 bytes)
> 
> 
> Is there any way to read out the current state of xfs_repair and tell
> what it is doing and when it will finish? I am aware that the end time
> is impossible to predict, I am just looking for ballpark figures.

to see if it's moving, I'd try stracing the process or examining it
with gdb if you are able.

You didn't say which version of xfsprogs you have; IIRC at least one known
problem with hanging has been fixed upstream.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs