xfs
[Top] [All Lists]

Re: xfs_repair misses an fs error?

To: Keith Keller <kkeller@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: xfs_repair misses an fs error?
From: Roger Willcocks <roger@xxxxxxxxxxxxxxxx>
Date: Tue, 16 Apr 2013 20:19:50 +0100
Cc: linux-xfs@xxxxxxxxxxx
Delivered-to: linux-xfs@xxxxxxxxxxx
In-reply-to: <6qi04axkbr.ln2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <k5gu3axace.ln2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20130416162557.GD13938@destitution> <6qi04axkbr.ln2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Tue, 2013-04-16 at 11:44 -0700, Keith Keller wrote:
> On 2013-04-16, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> >
> > Not recently. What version of xfs_repair are you using?
> 
> Hmm, perhaps this is a difference.  I believe (though, again I did very
> poor logging, and I apologize) that the initial repair used 3.1.1.  The
> recent successful repair definitely used 3.1.10.  Is it possible 3.1.1
> is old enough that it might not have caught the issues I reported from
> the 3.1.10 log?
> 

Yes, we had a system here for which xfs_repair 3.1.6 reported for 30 or
so files:

   data fork in regular inode 3238731555 claims used block 1080914355
   correcting nblocks for inode 3238731555, was 304 - counted 0

in phase three, and 

   correcting nblocks for inode 3238731555, was 0 - counted 304

in phase four, so the filesystem ended up back where it started. Version
3.1.8 fixed this, reporting instead e.g.:

   data fork in regular inode 3238731617 claims used block 1080933203
   correcting nextents for inode 3238731617
   correcting nblocks for inode 3238731617, was 304 - counted 0
   correcting nextents for inode 3238731617, was 1 - counted 0

> 
-- 
Roger Willcocks <roger@xxxxxxxxxxxxxxxx>

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