On Thu, Feb 28, 2008 at 07:20:41PM +0100, u+codalist-p4pg_at_chalmers.se wrote:
> $ cfs fr .
> 194 CML entries remaining for volume /some/tmp
> $
> ---------------------
> The volume is not replicated, if that matters.

Just checked locally, it doesn't seem to matter.

> If it is not meant to behave this way, then this is a bug?

I think so. The idea of forcereintegrate is that it provides a user
with a synchronization mechanism. Just looked at what is happening and
unfortunately force reintegrate cannot complete reintegration because
the act of reintegrating the store creates a (resolvable) conflict which
is resolved before we proceed. In order to allow resolution to obtain
the volume lock and fix the conflict, the reintegration thread exits
and returns to the user.

I guess in the single server case we are really being too pessimistic
and don't really need to interrupt reintegration to resolve because
there can't be a conflict between several servers, but that still
doesn't solve the more general case when there is replication.

This problem is really in the same area as another issue I was looking
at recently where we have a replicated volume, but the client is for
some reason (most likely because of a network timeout) disconnected from
one of the servers. The file creation is only sent to the visible
server, followed by the data store. Then we trigger resolution but it
fails because the "disconnected" replica which had not seen the file
creation event and so it doesn't know where to resolve the file data to
and the file is flagged as a conflict.

Jan