[ For future reference - can people keep triage on the public list so everyone can see that the problem is being worked on? ] On Fri, Dec 06, 2013 at 03:15:33PM -0800, Mike Dacre wrote: > On Fri, Dec 6, 2013 at 2:56 PM, Ben Myers <bpm@xxxxxxx> wrote: > > It's great that you have this. And an interesting repair log. > > The good news is that it doesn't look like the corruption that > > xfs_repair doesn't fix, the bad news is that I don't recognise > > it. > > Here is the repair log from right after the corruption happened. > The repair was successful. If xfs_repair didn't report any freespace corruption, then it's because it didn't see any. And that's not actually surprising for this sort of shutdown followed by log recovery failures. What it means the corruption was detected pretty much immediately after it occurred and the shutdown confined it to the log before it could be propagated to the in place metadata. Which generally means the shutdown occurred within 30s of it occurring. In my experience, this sort of "corruption confined to the log" shutdown is usually a result of some kind of memory corruption that is captured accidentally in the log due to object relogging (i.e. in a dirty region from a previous change that is not yet committed to the log) prior to it being detected in a transaction. Without being able to see the before/after log recovery filesystem images, there's nothing we can do to track this down further. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
