Messages in this thread | | | Date | Fri, 14 Dec 2012 10:52:49 +1100 | From | Dave Chinner <> | Subject | Re: XFS corruption on post 3.7 tree. |
| |
On Thu, Dec 13, 2012 at 04:41:19PM -0600, Ben Myers wrote: > Hi Dave, > > On Thu, Dec 13, 2012 at 05:10:57PM -0500, Dave Jones wrote: > > On Thu, Dec 13, 2012 at 03:55:22PM -0500, Dave Jones wrote: > > > Doing a kernel build while running on a 3.7+ tree from last night and I hit this... > > > > > > > > > [22637.787422] XFS: Internal error XFS_WANT_CORRUPTED_RETURN at line 163 of file fs/xfs/xfs_dir2_data.c. Caller 0xffffffffa070086a > > Looks like the dir v2 verifier found that a single block directory had a data > entry without a corresponding leaf entry in the block.
Actually, a data entry with a corresponding name hash entry. i.e. the data entry should contain XFS_DIR2_DATA_FREE_TAG, not contain a dirent....
> > I unmounted, remounted, unmounted, and then ran xfs_repair on it, as prompted. > > xfs_repair noted.. > > > > bad hash table for directory inode 201328949 (bad stale count): rebuilding
And that indicates that the header count of data and stale/free entries does not add up. That is, it found more less free entries than it shoul dhave, which means there was at least one entry that didn't have a XFS_DIR2_DATA_FREE_TAG value when it should have. That matches up precisely with the problem the write verifier reported.
> Interesting!
Very! The new metadata write verifiers appear to have exposed an existing silent directory corruption within a day of going upstream. :)
Now to try to find the needle in very complex haystack. :/
Cheers,
Dave. -- Dave Chinner david@fromorbit.com
| |