Re: force_shutdown experienced

[Stephen Lord <lord@xxxxxxx>]

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