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 -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
