I just tried with the latest util-vserver (0.30.216-1.pre2914), and the
effect is the same. As soon as a guest gets hashified, it's files are
The effect is quite interesting, though. The corruption isn't observable
until after a reboot.
Doing echo 3 > /proc/sys/vm/drop_caches results in the cache memory
going down to about 15MB. After hashifying, it dropping the caches again
makes it not go below 350MB. At this point, the files still check out as
being the same.
Then do a reboot, and all the hashified files will end up being trashed.
It doesn't matter if the files are merged between servers - the
unhashified servers stay healthy, but the hashified one (even if it is
the only hashified server!) is completely corrupted.
That implies that somehow the healthy files get wedged in caches that
cannot be dropped.
This is still with the 18.104.22.168-vs22.214.171.124.14-pre8 kernel. I haven't
tried a new kernel yet, that is next. I just wanted to rule out the
(extremely unlikely) possibility that the user-space was to blame. Will
report if the problem goes away with 126.96.36.199-vs188.8.131.52.33. If it
doesn't, I'll try with ext2 (rather than ext4 without the journal).
The only good thing about this is that the exercise seems to be 100%
repeatable. If anybody can think of any test cases to run that would
help get to the bottom of the cause of this, please do let me know.
Gordan Bobic wrote:
> Ghislain wrote:
>>> For completenes, the userspace packages I use are:
>>> The kernel is 184.108.40.206-vs220.127.116.11.14-pre8.
>> using vserver util from stable with 2.3 experimental kernel patch will
>> lead to troubles. You need to have a userland that match your kernel or
>> strange thing will happen. With 2.3 you MUST use 0.30.216, the latest
>> the better.
> I don't see 0.30.216 here yet:
>> john use the right combo of utils/kernel but you do not. I think this
>> can explain your weird issues (perhaps)
> I would have thought the hashify feature is pretty user-space (check
> hashes, and create hard-links, it's pretty much a job for a bash
> script), but I did find this:
> so I'll do a test with the current kernel and the latest bleeding edge
> My main suspect at the moment is an ext4 bug, though. If it doesn't go
> away with the latest kernel and userspace I'll try with ext2 and see if
> that makes the problem go away. But even if it does, this still needs to
> be investigated and the root cause identified, since it verifiably leads
> to file corruption.
Received on Wed Oct 20 13:04:09 2010