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
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
