On Tue, Apr 13, 2010 at 11:23:36AM +0200, Janos Haar wrote: > >If you run: > > > >$ xfs_db -r -c "inode 474253940" -c p /dev/sdb2 > > > >Then I can can confirm whether there is corruption on disk or not. > >Probably best to sample multiple of the inode numbers from the above > >list of bad inodes. > > Here is the log: > http://download.netcenter.hu/bughunt/20100413/debug.log There are multiple fields in the inode that are corrupted. I am really surprised that xfs-repair - even an old version - is not picking up the corruption.... > The xfs_db does segmentation fault. :-) Yup, it probably ran off into la-la land chasing corrupted extent pointers. > Btw memory corruption: > In the beginnig of march, one of my bets was memory problem too, but > the server was offline for 7 days, and all the time runs the > memtest86 on the hw, and passed all the 8GB 74 times without any bit > error. > I don't think it is memory problem, additionally the server can > create big size .tar.gz files without crc problem. Ok. > If i force my mind to think to hw memory problem, i can think only > for the raid card's cache memory, wich i can't test with memtest86. > Or the cache of the HDD's pcb... Yes, it could be something like that, too, but the only way to test it is to swap out the card.... > In the other hand, i have seen more people reported memory > corruption about these kernel versions, can we check this and surely > select wich is the problem? (hw or sw)? I haven't heard of any significant memory corruption problems in 2.6.32 or 2.6.33, but it is a possibility given the nature of the corruption. However, I may have only happened once and be completely unreproducable. I'd suggest fixing the existing corruption first, and then seeing if it re-appears. If it does reappear, then we know there's a reproducable problem we need to dig out.... > I mean, if i am right, the hw memory problem makes only 1-2 bit > corruption seriously, and the sw page handling problem makes bad > memory pages, no? RAM ECC guarantees correction of single bit errors and detection of double bit errors (which cause the kernel to panic, IIRC). I can't tell you what happens when larger errors occur, though... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>