XFS corruption

Dave Chinner david at fromorbit.com
Tue Dec 23 14:36:39 CST 2014


On Tue, Dec 23, 2014 at 11:57:13AM +0200, Alex Lyakas wrote:
> Hi Dave,
> 
> On Tue, Dec 23, 2014 at 2:39 AM, Dave Chinner <david at fromorbit.com> wrote:
> > commit 40194ecc6d78327d98e66de3213db96ca0a31e6f
> > Author: Ben Myers <bpm at sgi.com>
> > Date:   Fri Dec 6 12:30:11 2013 -0800
> >
> >     xfs: reinstate the ilock in xfs_readdir
> >
> >     Although it was removed in commit 051e7cd44ab8, ilock needs to be taken in
> >     xfs_readdir because we might have to read the extent list in from disk.  This
> >     keeps other threads from reading from or writing to the extent list while it i
> >     being read in and is still in a transitional state.
> >
> >     This has been associated with "Access to block zero" messages on directories
> >     with large numbers of extents resulting from excessive filesytem fragmentation
> >     as well as extent list corruption.  Unfortunately no test case at this point.
> >
> >     Signed-off-by: Ben Myers <bpm at sgi.com>
> >     Reviewed-by: Dave Chinner <dchinner at redhat.com>
> >
> > Seems to match the behaviour being seen.
> >
> > Alex, what type of inode is the one that is reporting the "access to
> > block zero" errors?
> I have just searched the relevant file system for this inode, but such
> inode was not found:(
> # find /export/XXX -mount -inum 1946454529
> did not find anything. Perhaps it got deleted since the incident.

It probably got cleared by xfs_repair because it was corrupt....

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com



More information about the xfs mailing list