On 8/17/17 7:13 AM, Hannes Reinecke wrote:

Hi all,

Hi Hannes - 
 

I've managed to corrupt my fs after a storage array failure earlier this
week. After calling 'xfs_repair -L' on the FS running xfs_repair
consistently gives me:

# xfs_repair /dev/dm-2
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
bogus .. inode number (0) in directory inode 128, clearing inode number
        - 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
        - agno = 2
        - agno = 1
        - agno = 3
bogus .. inode number (0) in directory inode 128, clearing inode number
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

irrespective on how many times I'm calling xfs_repair.
(And yes, this is with latest xfsprogs)

Which version, specifically?

Would you be willing to provide a compressed xfs_metadump (offline, probably),
and then I could take a look at the behavior directly?  Would be easier
than reverse engineering it from the printfs above.  :)

(note, metadump is still leaking a bit of stale data here and there,
so treat the file accordingly if there's anything sensitive on the
filesystem)

Thanks,
-Eric