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
> 188.8.131.52-0.1-xen #1
> Jun 7 03:06:31 orion.i.zmi.at kernel:
Hm, the other sort of interesting thing here is that a recently-reported
[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