Jan 3 03:03:54 kernel: iput: inode 28345 on device 08:19 still has mappings.
Jan 3 03:06:38 kernel: iput: inode 3669 on device 08:12 still has mappings.
Jan 3 03:06:38 kernel: Inode i_mmap ring corrupted
Jan 3 03:09:43 kernel: Inode i_mmap ring corrupted
Jan 3 03:10:49 kernel: Inode i_mmap ring corrupted
Some minutes later, the machine crashed. These errors were strange,
because there is no /dev/sda12 partition and the /dev/sdb3 partition is
unused and never mounted. Ok, we buyed a watchdog, upgraded the kernel
(from 2.0.31), improved the lousy software dealing with 70.000 files in
one directory. So far the same machine was not affected again.
Yesterday I had the chance to see SCSI-errors on a totally different
machine running 2.0.33. Once again the errors were reported on a
non-existing partition:
EXT2-fs warning (device 08:14): ext2_free_inode: bit already cleared for inode 693269
SCSI disk error : host 0 channel 0 id 1 lun 0 return code = 28000002
The device 08:14 is /dev/sda14 and non-existant. Although /dev/sda was
replaced yesterday, similar errors occur (it's not my machine (anymore),
so I can only repeat what they told me). The second error is usally
accompanied with a drop in spin-frequency (iiiiiuiuiuuuu uuuuiuiuiiiiiii
<click> [I can tell you, it's really creepy if the room becomes silent for
1 second at 3 am]) so it's likely that there are hardware-errors on
/dev/sdb [10GB disk with a seperate power supply and a strong cooling].
Further investigations will hopefully clear up the situation.
Ah, yes, this machine deals with many files (120.000) in one directory,
too. That's the (only) property both machines/errors have in common (the
files were even of different size, 10byte vs. 3kbyte).
But I still wonder: why do errors happen on non-existing devices (the
errors seem to "wrap" from /dev/sdb to /dev/sda in both cases).
-Winfried