xfs
[Top] [All Lists]

Re: xfs_repair segfaults

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfs_repair segfaults
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 01 Mar 2013 16:32:19 -0600
Cc: Ole Tange <tange@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130301223116.GE23616@dastard>
References: <CANU9nTnvJS50vdQv2K0gKHZPvzzH5EY1qpizJNsqUobrr2juDA@xxxxxxxxxxxxxx> <5131283F.8030704@xxxxxxxxxxx> <20130301223116.GE23616@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
On 3/1/13 4:31 PM, Dave Chinner wrote:
> 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....

Yep and that's what lights up when repair -L runs too.

Ole, you can xfs_mdrestore your metadump image and run test repairs on the 
result,
if you want a more realistic "dry run" of what repair would do.

-Eric

> Cheers,
> 
> Dave.
> 

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