[Top] [All Lists]

Re: bad fs - xfs_repair 3.01 crashes on it

To: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Subject: Re: bad fs - xfs_repair 3.01 crashes on it
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sun, 12 Jul 2009 13:52:20 -0500
Cc: xfs mailing list <xfs@xxxxxxxxxxx>
In-reply-to: <200907031320.48358@xxxxxx>
References: <200907031320.48358@xxxxxx>
User-agent: Thunderbird (Macintosh/20090605)
Michael Monnerie wrote:
> Tonight our server rebooted, and I found in /var/log/warn that he was crying 
> a lot about xfs since June 7 already:
> Jun  7 03:06:31 orion.i.zmi.at kernel: Filesystem "dm-0": corrupt inode 
> 3857051697 ((a)extents = 5).  Unmount and run xfs_repair.
> Jun  7 03:06:31 orion.i.zmi.at kernel: Pid: 23230, comm: xfs_fsr Tainted: G   
> #1
> Jun  7 03:06:31 orion.i.zmi.at kernel:

Hm, the other sort of interesting thing here is that a recently-reported
RH bug:

[Bug 510823] "Structure needs cleaning" when reading files from an XFS
partition (extent count for ino XYZ data fork too low (6) for file format)

also seems to -possibly- be related to an xfs_fsr run, and also is
related to extents in the wrong format.  In that case it was the
opposite; an inode was found in btree format which had few enough
extents that it should have been in the extents format in the inode; in
your case, it looks like there were too many extents to fit in the
format it had...

Just out of curiosity, it looks like you have rather a lot of extended
attributes on at least the inode above, is that accurate?  Or maybe
that's part of the corruption?

I'll focus on getting xfs_repair to cope first, but I wonder what
happened here...


<Prev in Thread] Current Thread [Next in Thread>