xfs
[Top] [All Lists]

Re: [PATCH 0/4] repair: fixes for 3.2

To: Arkadiusz MiÅkiewicz <arekm@xxxxxxxx>
Subject: Re: [PATCH 0/4] repair: fixes for 3.2
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 2 Jul 2014 06:03:31 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <201407011540.57511.arekm@xxxxxxxx>
References: <1404219296-29302-1-git-send-email-david@xxxxxxxxxxxxx> <201407011540.57511.arekm@xxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Jul 01, 2014 at 03:40:56PM +0200, Arkadiusz MiÅkiewicz wrote:
> On Tuesday 01 of July 2014, Dave Chinner wrote:
> > Hi Arkadiusz,
> > 
> > These are the fixes I have so far from working through the metadumps
> > you supplied me with. The unobfuscated metadump repairs cleanly with
> > these patches, but the obfuscated one still has a directory rebuild
> > issue that I haven't got to the bottom of yet. That results in
> > an error in phase 6 like:
> > 
> > Metadata corruption detected at block 0x2af84770/0x1000
> > name create failed in ino 2306912354 (117), filesystem may be out of space
> > 
> > It appears that a read verifier is on a recently created
> > directory leaf block and that is failing. I'm not yet sure why the
> > leaf block is corrupt, nor why the verifier is even being run on it
> > seeing as it was only allocated and initialised during the directory
> > rebuild. That directory rebuil dfailure is the reason for all the
> > disconected inode that end up in lost+found, and I think it's the
> > only remaining issue that I need to solve.
> > 
> > Can you test the patches on you machine and see if you get the same
> > results?
> 
> Testing on non obfuscated image here.
> 
> Most of issues got fixed, first xfs_repair run:
> http://ixion.pld-linux.org/~arekm/p2/x1/repair-3.2-dchinner1-4patches-run1.txt
>  
> 
> second xfs_repair run (reports no problems):
> http://ixion.pld-linux.org/~arekm/p2/x1/repair-3.2-dchinner1-4patches-run2.txt
> 
> When trying to mount
> "XFS (loop0): Failed to initialize disk quotas."
> so this issue left.

Yeah, I haven't got that far yet....

> Question:
> 
> Phase 2 - using internal log
>         - zero log...
> zero_log: head block 2 tail block 2
>         - scan filesystem freespace and inode maps...
> Metadata CRC error detected at block 0x0/0x200
> 
> Is "Metadata CRC error detected at block" expected here? I mean v4 fs, so no 
> CRC.

Given that it was followed by:

zeroing unused portion of primary superblock (AG #0)

Then there was garbage in the superblock that made the verifier
think that maybe it was missing a feature bit. It didn't come up the
second time, so everything is fine....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>