(Illustration by Gaich Muramatsu)
On Wed, Feb 25, 2004 at 12:30:14PM +0100, Ivan Popov wrote: > Let us see. Imagine a double replicated volume. > One of the servers can be remarkably slower than the other, > because of hardware or load. > If a client makes massive modifications, it will talk to the faster > server, never enter its own "yellow" or "red" zones and happily send > lots of data... If the client is fully connected, it will send all modifications to both server simulaneously, and will run at the speed of the slowest server. When that speed is below the weak-connectivity threshold, the server will switch to write-disconnected and reintegrate with the faster server. But after every reintegration it will trigger resolution and not continue until resolution has completed. So reintegration should again only progress as fast as the slowest server. The only time that the resolution log could overflow is when the client is repeatedly disconnected from one server before the 2nd phase commit message is sent. This could happen if it consistently times out during operations. > Is it possible to have something like yellow/red zone detection > on server volume modification logs? In principle there should be code that reuses the oldest entries in the resolution log when it fills up. The effect of this is that log-based resolution will fail for directories that have very old entries, but other types of resoltion such as runt (server doesn't even know about the object) and weak equality resolution (server missed the last 2nd phase commit message) will still work fine. However the reuse code is either broken or intentionally disabled, I'm not sure. The assertion that currently kills the server occurs because the 'AllocViaWrapAround' function didn't find an eligible log entry to recycle. JanReceived on 2004-02-26 01:03:42