On Freitag 06 November 2009 Eric Sandeen wrote:
> > I had that during the last days on my system. It kept on running
> > despite
> > this error. I xfs_repair'ed the fs again and now it's working.
> > This is the same server I talked about with Eric last time, where
> > he improved xfs_repair and that repaired my fs. I had to run
> > xfs_repair several times again until all errors were solved,
> > and now nothing is reported anymore.
> > The server had no crash or whatever since the last repair, so I
> > wonder where these corruptions come from.
> > Nov 2 00:01:12 orion.i.zmi.at kernel: Filesystem "dm-0": corrupt
> > inode 3858839593 ((a)extents = 7). Unmount and run xfs_repair.
> Just FWIW this is not a crash, it is XFS properly handling
> corrruption it encountered. The corruption could be due to a bug
> in XFS or other code, or a hardware problem. Does repair fix it this
Yes Eric, that's what I wrote but I see it can be misinterpreted as
belonging to the old case. I meant the actual problem when saying:
I had to run xfs_repair several times again until all errors were
solved, and now nothing is reported anymore. The server had no crash or
whatever since the last repair, so I wonder where these corruptions come
Seems to be time to make a memory check. I have no other idea where the
problem could come from.
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4