Dexter Filmore wrote: > Am Dienstag, 10. Oktober 2006 05:23 schrieb James G. Sack (jim): >> Dexter Filmore wrote: >>> When I copy a lot of small files on a file server, it eventually shuts >>> down the fs. >>> Looks like this in dmesg: >>> >>> [ 1734.674678] xfs_force_shutdown(dm-1,0x8) called from line 1139 of file >>> fs/xfs/xfs_trans.c. Return address = 0xc0297f83 >>> [ 1734.694671] Filesystem "dm-1": Corruption of in-memory data detected. >>> Shutting down filesystem: dm-1 >>> [ 1734.694689] Please umount the filesystem, and rectify the problem(s) >>> >>> Is this an xfs issue or a hardware problem? >>> >>> Said xfs sits on top of a LVM2 volume which sits on a software raid5 with >>> sATA disks on a SIL3112 controller. >>> Slackware 11.0, but occured on 10.2 as well. >> I've seen <similar> messages tracable to LVM snapshots. Are you using >> any lvm snapshots? Do you have any 'smart' backup operations doing >> dmsetup suspend/resume >> or >> xfs_freeze/xfs_freeze -u > > At least none which I am aware of. I didn't install any such. > >> Of course, maybe there _really_ is something bad on one of the disks, >> and raid5 might be failing a read. On a write, the disk might be doing >> auto remapping -- but failed reads are actually nastier! > > raid is fine, smartctl looks good.
My reference to read failures above is likely a red herring, since a read failure would lead to failing a raid member disk. Searching on Corruption of in-memory data detected. Shutting down filesystem: dm does lead to some reading material, including, for example http://oss.sgi.com/projects/xfs/faq.html#dir2 Since the error is memory-related, you might consider an extended memtest86 run -- by which I mean multiple passes, say overnight. Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
