xfs_repair has been running a day is it actually doing anything?

Question

I am having a problem with my 1 TB XFS LVM logical volume. This formerly resided on a physical volume which developed IO errors, so I used "pvmove" to migrate to a new disk. After the migration I was able to read from and write to the volume, but started seeing "structure needs cleaning" errors. So I decided to unmount the volume and run xfs_repair.

This started out with the following messages (I've replaced some of the often-repeated redundant-looking messages with "<snipped>" to reduce the volume of text):

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
entry "/rca.orca_gui_find.indexcache.2012-11-13T22:29:05-05:00.snapshot.gz" at block 147
        clearing inode number in entry at offset 2912...
entry at block 147 offset 2912 in directory inode 1893017 has illegal name "/rca.orca_gui
<snipped>
entry at block 0 offset 1616 in directory inode 3728154 has illegal name "/andler.html.zh
cleared inode 3728972
imap claims a free inode 3729023 is in use, correcting imap and clearing inode
cleared inode 3729023
<snipped>
bad magic number 0x0 on inode 3729024
bad version number 0x0 on inode 3729024
<snipped>
entry "/gi.html.en" at block 0 offset 696 in directory inode 3729503 references invalid i
        clearing inode number in entry at offset 968...
<snipped>
entry at block 0 offset 968 in directory inode 3729503 has illegal name "/taccess.html": 
        will junk block
no . entry for directory 3996998
no .. entry for directory 3996998
problem with directory contents in inode 3996998
cleared inode 3996998
bad directory block magic # 0 in block 0 for directory inode 3997000
<snipped>
agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
bad directory block magic # 0 in block 0 for directory inode 4003024
corrupt block 0 in directory inode 4003024
        will junk block
no . entry for directory 4003024
no .. entry for directory 4003024
entry "Authoring.pod" at block 0 offset 160 in directory inode 14276983 references free i
        clearing inode number in entry at offset 160...
entry "Base.pm" at block 0 offset 216 in directory inode 14276983 references free inode 3
<snipped>
        - agno = 1
entry "wireless" at block 0 offset 688 in directory inode 2207138636 references free inod
        clearing inode number in entry at offset 688...
entry "xfrm" at block 0 offset 728 in directory inode 2207138636 references free inode 39
        clearing inode number in entry at offset 728...
entry "seq" at block 0 offset 64 in directory inode 2207276722 references free inode 4001
        clearing inode number in entry at offset 64...
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...

Since yesterday, xfs_repair has stopped outputting anything new to the screen. I checked with strace, but I don't see any activity. The xfs_repair process still exists in the process table, and is consuming memory but no CPU.

So is it doing anything? Should I let it run, or terminate the process? Will I be able to use the existing filesystem, or will I need to start over with a new, clean XFS volume instead?

Answer 1

I think what I might do is stop the process, reboot the machine, see if the "repaired" segment is mountable....if so no problem. If not, then you can restart the process again.

Just how big is the partition you are attempting to convert?