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.

Jan