how to decode metadump info produced by xfs_db, and superblock error

how to decode metadump info produced by xfs_db, and superblock error

[lord worm]

[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --]


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?
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 854 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

FW: how to decode metadump info produced by xfs_db, and superblock error

[lord worm]

[-- Attachment #1.1: Type: text/plain, Size: 2130 bytes --]


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@live.com
To: xfs@oss.sgi.com
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?
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 3321 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: how to decode metadump info produced by xfs_db, and superblock error

[Stan Hoeppner]

lord worm put forth on 1/29/2011 6:25 PM:
> 
> 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?


dd is not a proper XFS filesystem backup/restore utility.  Instead use xfsdump
and xfsrestore, or any file level backup/restore solution.

You obviously now know why you shouldn't use dd for this purpose with XFS. ;)

-- 
Stan

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

Re: how to decode metadump info produced by xfs_db, and superblock error

[Dave Chinner]

On Sat, Jan 29, 2011 at 07:25:10PM -0500, lord worm wrote:
> 
> 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).

dmesg output when the mount fails?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: how to decode metadump info produced by xfs_db, and superblock error

[Dave Chinner]

On Sun, Jan 30, 2011 at 08:21:19PM -0500, lord worm wrote:
> > Date: Mon, 31 Jan 2011 08:40:26 +1100
> > From: david@fromorbit.com
> > To: cryptopsy@live.com
> > Subject: Re: how to decode metadump info produced by xfs_db, and superblock error
> > 
> > On Sun, Jan 30, 2011 at 11:33:53AM -0500, lord worm wrote:
> > > > Date: Sun, 30 Jan 2011 18:16:30 +1100
> > > > From: david@fromorbit.com
> > > > To: cryptopsy@live.com
> > > > CC: xfs@oss.sgi.com
> > > > Subject: Re: how to decode metadump info produced by xfs_db, and superblock error
> > > > 
> > > > On Sat, Jan 29, 2011 at 07:25:10PM -0500, lord worm wrote:
> > > > > 
> > > > > 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).
> > > > 
> > > > dmesg output when the mount fails?
> > > 
> > > Could you email the mailing list next time as well, so that my
> > > forwards are directed towards everyone, please?
> > 
> > I did:
> > 
> > http://oss.sgi.com/archives/xfs/2011-01/msg00486.html
> > 
> > As for list ettiquette - please don't top post and wrap all you text
> > except for code and pasted log messages at 72 columns.....

Fixed that for you again.

> > > Here's dmesg from the backup file, but I don't have it from the original disk after restoring it:
> > > 
> > > [  362.685464] attempt to access beyond end of device
> > > [  362.685468] loop5: rw=0, want=15662872, limit=15661056
> > > [  362.685473] I/O error in filesystem ("loop5") meta-data dev loop5 block 0xeeff17       ("xfs_read_buf") error 5 buf count 512
> > > [  362.685478] XFS: size check 2 failed
> > 
> > Simple problem - you copied the filesystem back onto a device that
> > is too small for the filesystem.
> 
> When I reply to this email, it defaults to david@fromorbit.com, so
> how will the others see it?

Reply to all. It's common courtesy to reply to everyone on the
cc-list for mailing list traffic as it often contains people not
subscribed to the mailing list (e.g. a person reporting a bug).

I've added the xfs list back onto the cc-list.

> I can't mount the direct dd image of the drive as a loop device
> either by the same error.

Which means you probably didn't copy the entire drive in the first
place.

> The error persists even when its not
> the filesystem that was copied back onto the device. Additionally,
> its the exact same device with the exact same partition type
> created by the exact same version of disk.

partition type doesn't matter - the size does. The above error
indicates that the loop device is 1816 sectors (908kiB) shorter than
it needs to be, so maybe you aren't recreating the partition as
large as it needs to be, too....

As it is, the question I have at this point is why are you trying to
copy the filesystem via dd? if all you want is an image, xfs_copy is
probably what you want....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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