@djsmiley2k Do you remember my ill-fated server? I promised to give you a follow-up in case I find something interesting. Sadly I still could not allocate enough time to get back to it (it was kinda-operational and was left on its own since then). Peculiar thing is that some directories if dumped with debugfs show alien characters in names, like 0x80. What is so wonderfull about this is that they are squeezed in between valid ones and not instead of them.

Which I would expect in the event of checksum-based recover or something like that

But wait, there is more :) This week we did an ordinary rack maintenance (exactly the rack that server is located at). Guess what happened upon reboot? LDAP database again was corrupted, but it managed to self-repair and got up and running, Mysql server however did fail and could not repair itself even after several restart attempts. Didn't bother to do anything about it as there was another maintenance next day scheduled.

Next day -- another restart and.. BAM just after loading kernel it gave us "cpu stall detected" -type message twice. Hard-reset solved it and it started properly. You wouldn't believe but this time Mysql did repair its database (even though I did restart it several times before to no avail!) and was running happily!

Looks like data loss is coincident to reboot, but what may cause it? Could it be an old CPU degraded past undetectable "memory loss" to forget to dump caches to RAID.... It's getting more and more absurd...

BTW I did create a fresh empty filesystems on it without errors, but it still managed to corrupt files after restart somehow... :(