Coda File System

Re: what about adding such cfs subcommand?

From: <>
Date: Thu, 28 Feb 2008 21:02:02 +0100
On Thu, Feb 28, 2008 at 02:18:57PM -0500, Jan Harkes wrote:
> I think so. The idea of forcereintegrate is that it provides a user
> with a synchronization mechanism. Just looked at what is happening and

My impression was that forcereintegrate is a means to initiate a try
to reintegrate, not to wait until the volume is fully synchronized
(which potentially can take a very long time and include other, newer
CML entries than those the caller was interested in). So I am not
opposed to the behaviour per se.

> 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.

Why not just retry?

> 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.

It seems I have to refresh my knowledge of resolution.
Isn't the create operation present in the server volume modification logs
which they are to exchange? (You don't have to explain resolution
once again here - unless you feel inclined so. I'll go and read elsewhere).

Best regards,
Received on 2008-02-28 15:03:00