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
>>> 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
> 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
if you want a more realistic "dry run" of what repair would do.