Bugzilla – Bug 247
xfs_force_shutdown
Last modified: 2008-12-27 03:16:43 CST
I am using Turbo linux sever 8 with xfs. I experienced xfs_force_shutdown almost every day while deleting back up directory with rm -rf xxxx/ command. Log Messages show as follows. May 30 05:21:34 mpzserver2 kernel: xfs_force_shutdown(ide1(22,2),0x8) called from line 4065 of file xfs_bmap.c. Return address = 0xd32a15e1 May 30 05:21:34 mpzserver2 kernel: Corruption of in-memory data detected. Shutting down filesystem: ide1(22,2) May 30 05:21:34 mpzserver2 kernel: Please umount the filesystem, and rectify the problem(s) After unmount device and perform xfs_repair usually show following messages. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Then, I remounted device and unmont again and perform xfs_repair to fix it. Is this considered real memory problem or some bug in xfs file system? I am using regular DIMM ram without ECC. Please help me. Mike Shimura
XFS corruption after transfering large ammount of data (~360GB) to RAID5. System has been working during 4 days. Data transfers via CIFS/SMB with breaks and with a few connections at the same time. [root@HOST23002006 root]# xfs_repair /dev/evms/Volume1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. [root@HOST23002006 root]# mount -o ro /dev/evms/Volume1 /drives/Volume1/ mount: Unknown error 990 uname -rmis Linux 2.6.10-sanmina-aw22 armv5tel unknown
The second issue reported is the same as bug #755, as these are the symptoms for the cache aliasing problems on virtual indexed caches. As for the first one without actually seeing the filesystems we can't really say much about it. *** This bug has been marked as a duplicate of 755 ***