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