On 12/22/2011 8:08 AM, hydra wrote: > Hello Timo, thank you for the reply. I was suspecting the same. However: > - the machine runs under Vmware, > - I've tried 3 different kernel versions, > - I've tried 3 different SCSI controllers. > > All same results.
dmesg output? Log errors? Is your EXT4 filesystem on a VMFS volume or an RDM (SAN LUN)? > On Wed, Dec 21, 2011 at 6:16 PM, Timo Sirainen <t...@iki.fi> wrote: > >> On 21.12.2011, at 18.38, hydra wrote: >> That's a kernel process.. >> >>> I suspect, that this is something to do with Dovecot, because after >>> deleting the dovecot.index.cache file, everything went back to normal. >> When >>> this happens, I cannot unmount the drive nor a system reboot works. System (host machine) reboot, or virtual machine reboot doesn't fix the problem? FYI, Linux doesn't unmount drives, it unmounts filesystems. I'd say you may have a problem with your VMFS volume or RDM, or maybe just your EXT4 filesystem. Have you run an fsck on it? What result? Or, as Timo suggests, could be a kernel bug. Or an interaction of these low level layers causing a problem. If you can't unmount a filesystem, that has nothing to do with Dovecot, and points to a much larger, more critical, problem. Do you have this problem when booting an older kernel? Say 2.6.32? 2.6.37? >> That's a kernel bug.. >> >> I think you're thinking it the wrong way: Dovecot isn't causing your >> system to break. Your system is causing Dovecot to break. Faulty hardware >> or faulty kernel. -- Stan