Subject: Re: [vserver] Possible Hashify Corruption
From: Gordan Bobic <gordan@bobich.net>
Date: Sun, 17 Oct 2010 15:32:22 +0100

On 17/10/2010 14:51, Ben Green wrote:
> Quoting "Gordan Bobic" <gordan@bobich.net>:
>
>>
>> I'm running 2.6.30.10-vs2.3.0.36.14-pre8. The file system is ext4
>> without journal and in data=writeback mode.
>
> Wasn't EXT4 only just added to the kernel at that point? It produces
> data loss situations in kernel much later than that even, so corruption
> with 2.6.30 doesn't seem out of the question.

That does indeed seem plausible. But if that is the case, how come all 
the host files are healthy? and how come the text files in /etc are OK? 
The only thing i can think of here is that there is some kind of a 
hard-linking bug in ext4 in that particular kernel that killed it. 
Having said that, hashify would have done the same with text files, and 
the text files in etc seem to be OK, including the ones that haven't 
been touched since the original installation. But is it really possible 
that if it is a bug in ext4 or the interraction between ext4 and vserver 
on that particular kernel, it never bit anyone before?

The reason why I am on 2.6.30.10 is because it is the latest version 
that has iptables TARPIT target patches (a bit obscure, but this system 
will be in a hostile network environment). But I guess in light of this, 
a newer kernel might be worth trying.

I'll re-build the machines from the RPM lists and restore their /etc 
directories and re-hashify them, bounce the host and see if it happens 
again. But in a way, the worst that could happen then is that everything 
is OK, as that would make it impossible to get to the bottom of the 
initial cause. I don't have prelink installed on the host or the guests, 
so that is out as a possibility of what might have killed it.

Gordan