It's definitely a VMware problem.
It took us weeks to figure that out. We even have bought a completely new PC since we first thought about hardware problems, and were very surprised by getting the same problems on the new PC, too. And as already written we were finally able to isolate the problem to VMware. If a partition only used for the VMs and nothing else get corrupted after a simple "Start Debian 7 VM", "apt-get update && apt-get dist-upgrade", "Shut down Debian 7 VM" (or something similar done with a different VM), and this happened on two different PCs (and on three different hard disks), reproducible, than VMware must be the problem:
Code: Select all
[root@xxx yyy]# fsck -f /dev/sda6
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Inode 393222, end of extent exceeds allowed value
(logical Block 1483744, physical Block 537599, len 7296)
Bereinige<j>? ja
Inode 393222, i_Blocks ist 11928328, sollte sein 11869960. Repariere<j>? ja
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
Block Bitmap differieren: -(537599--544894)
Repariere<j>? ja
Die Anzahl freier Blöcke in Gruppe #16 ist falsch (12161, gezählt=19457).
Repariere<j>? ja
Die Anzahl freier Blöcke ist falsch (38323887, gezählt=38331183).
Repariere<j>? ja
/dev/sda6: ***** DATEISYSTEM WURDE VERÄNDERT *****
/dev/sda6: 1737/14508032 Dateien (0.1% nicht zusammenhängend), 19668945/58000128 Blöcke
[root@xxx yyy]#
(This was tested with RHEL 6.4 and CentOS 6.4 and VMware Workstation 9, with latest updates.)
I guess it's so hard to find this problem description (and solution) in the net because the CentOS installer formats ext4 partitions with a maximum mount count number of 0, i.e. it will never been checked on boot time unless the clean bit is not set (and usually it's set if you shut down your CentOS 6 properly.) So unless you do not change the maximum mount count number or force a filesystem check with "fsck -f" you will maybe never notice these problems.
drk wrote:Can you repeat your test using KVM instead?
After switching to KVM the problem has gone away. We still check the filesystem on every boot (since "tune2fs -c 1 /dev/sda6" was set), and the PC will be booted on every working day but no problem was reported since we have switched to KVM on Nov 2013.
