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
Received on Sun Oct 17 15:32:30 2010