|
I supposed I should have added the output of xfs_repair -n -o assume_xfs /mybackupfile.bak (but I know you use the metadump file for real debugging ...). It seems the superblock is correct, so either mount is wrong in sayings it incorrect (and something else is the problem), or the superblock is broken and xfs_repair cannot detect (also broken): Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - 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 = 1 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. From: cryptopsy@xxxxxxxx To: xfs@xxxxxxxxxxx Subject: how to decode metadump info produced by xfs_db, and superblock error Date: Sat, 29 Jan 2011 19:25:10 -0500 What kind of information is in this file produced by metadump, is it worth reading it somehow? I'm trying to first understand what's causing a 'superblock cannot be read' error in my XFS after a succesfully dd of the partition (dd succeeds in copying to a file, and also restoring, but after restoring it cannot mount). xfs_repair fails to fix it, how should I attach the 55M metadata file to this email (do we have an upload location for this?), max size on hotmail is 25M ... Does the superblock error refer to primary or secondary superblocks? Does xfs_repair attempt to clone the broken superblock from the others? |
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
