Re: Serious XFS crash

[David Chinner <dgc@sgi.com>]

On Tue, Mar 25, 2008 at 06:54:53PM +0100, Emmanuel Florac wrote:
> 
> Here is the setup : Debian sarge running kernel 2.6.18.8 smp (clean
> build), xfsprogs version 2.6.20 (not used). An 8TB xfs filesystem broke
> apart losing roughly 2TB of data in about 350 (big) files :
> 
> Mar 22 12:38:18 system3 kernel:
> 0x0: c0 49 00 35 6a bc c3 80 fd d4 64 f8 16 ec b9 85 
       | forw    | | back    | |mg1| |pad|

#define XFS_DA_NODE_MAGIC       0xfebe  /* magic number: non-leaf blocks */
#define XFS_ATTR_LEAF_MAGIC     0xfbee  /* magic number: attribute leaf blks */
#define XFS_DIR2_LEAF1_MAGIC    0xd2f1  /* magic number: v2 dirlf single blks */
#define XFS_DIR2_LEAFN_MAGIC    0xd2ff  /* magic number: v2 dirlf multi blks */

> 0x0: c0 49 00 35 6a bc c3 80 fd d4 64 f8 16 ec b9 85 
       |hdr.magic|

#define XFS_DIR2_BLOCK_MAGIC    0x58443242      /* XD2B: for one block dirs */
#define XFS_DIR2_DATA_MAGIC     0x58443244      /* XD2D: for multiblock dirs */

So none of the magic numbers for a directory block match.
And FWIW, I can't see any XFs magic number in that block.

> As a precaution, I booted with a live CD with xfsprogs 2.8.11. I first
> ran xfs_repair -n :
> 
> No modify flag set, skipping phase 5
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - scan filesystem freespace and inode maps...
> bad magic # 0x7c6999f7 for agf 0
> bad version # 270461846 for agf 0
> bad sequence # -506160237 for agf 0
> bad length 1130385756 for agf 0, should be 68590288
> flfirst 260475029 in agf 0 too large (max = 128)
> fllast -1448142937 in agf 0 too large (max = 128)
> bad magic # 0xfffde400 for agi 0
> bad version # -1469688457 for agi 0
> bad sequence # 2021095287 for agi 0
> bad length # 2004318207 for agi 0, should be 68590288
> would reset bad agf for ag 0
> would reset bad agi for ag 0
> bad uncorrected agheader 0, skipping ag...
> root inode chunk not found

Oh, that's toast. Something has overwritten the start of the
filesystem and it does not appear to be other metadata.  Well, not
exactly the start of the filesystem - the superblock is untouched.

What sector size is being used for the XFS filesystem? If it's
not the same as teh filesystem block size, then XFS can't have done
this itself because the offset that this garbage starts at would
not be block aligned.....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group