Robert Sander wrote:
Hi!
This morning I saw this in the logfile:
Mar 15 09:30:39 raman kernel: xfs_force_shutdown(sd(8,18),0x8) called from line
4079 of file xfs_bmap.c. Return address = 0xf89692a2
Mar 15 09:30:39 raman kernel: Corruption of in-memory data detected. Shutting
down filesystem: sd(8,18)
Mar 15 09:30:39 raman kernel: Please umount the filesystem, and rectify the
problem(s)
After reading the FAQ and the mailing list archive it seems that a
simple umount and mount could slove the problem. But:
Mar 15 10:21:40 raman kernel: XFS: bad magic number
Mar 15 10:21:40 raman kernel: XFS: SB validate failed
The primary superblock was corrupted. Running xfs_repair produced some
files in lost+found and the message that sunit and swidth are being
resetted and should be specified in the mount options.
I haven't used these options for mkfs.xfs so I did not specify them when
mounting the repaired filesystem. The mount worked and the filesystem
looks godd at a first glance (execpt for the file in lost+found...).
Are we still able to use that filesystem?
Kernel is 2.4.17 from CVS compiled on Jan 4th, filesystem is on an
external HW-RAID which does not report errors.
Greetings
Well, two things happened to you - the forced shutdown, and the bug
which Ralf Bergs
mentioned. That bug was fixed on Jan 17th - a current cvs kernel should
get you around
that one. The bug caused the superblock to get overwritten after forced
shutdown.
Note if you get the new kernel and you use ACLs you need new user space
utilities
to go with the kernel.
I would unmount the filesystem and run xfs_check on it to verify it is
clean, but repair
should have handled everything.
I do not think we will be able to determine the cause of the memory
corruption
from the information we have here.
Steve
|