xfs
[Top] [All Lists]

Re: xfs_repair segfaults

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: xfs_repair segfaults
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 2 Mar 2013 09:31:16 +1100
Cc: Ole Tange <tange@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <5131283F.8030704@xxxxxxxxxxx>
References: <CANU9nTnvJS50vdQv2K0gKHZPvzzH5EY1qpizJNsqUobrr2juDA@xxxxxxxxxxxxxx> <5131283F.8030704@xxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Mar 01, 2013 at 04:14:23PM -0600, Eric Sandeen wrote:
> On 2/28/13 9:22 AM, Ole Tange wrote:
> > I forced a RAID online. I have done that before and xfs_repair
> > normally removes the last hour of data or so, but saves everything
> > else.
> > 
> > Today that did not work:
> > 
> > /usr/local/src/xfsprogs-3.1.10/repair# ./xfs_repair -n /dev/md5p1
> > Phase 1 - find and verify superblock...
> > Phase 2 - using internal log
> >         - scan filesystem freespace and inode maps...
> > flfirst 232 in agf 91 too large (max = 128)
> > Segmentation fault (core dumped)
> 
> FWIW, the fs in question seems to need a log replay, so 
> xfs_repair -n would find it in a worse state...
> I had forgotten that xfs_repair -n won't complain about
> a dirty log.  Seems like it should.
> 
> But, the log is corrupt enough that it won't replay:
> 
> XFS (loop0): Mounting Filesystem
> XFS (loop0): Starting recovery (logdev: internal)
> ffff88036e7cd800: 58 41 47 46 00 00 00 01 00 00 00 5b 0f ff ff 00  
> XAGF.......[....
                                                     ^^
It's detecting AGF 91 is corrupt....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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