Coda File System

Re: coda reintegration in write-disconnected mode

From: Juan Carlos Schroeder <jcsc_at_adinet.com.uy>
Date: Sat, 10 Jul 2004 00:38:12 -0300
Ok, thank you both for the answers.

I still have some doubts on this.
How does venus decide when to start 'reintegrating'? As I wrote in the
previous message, I've seen this is about 1 or 2 minutes after last
modification.
If I don't want venus to be reintegrating every 2 minutes (f.i.: having
constant modifications to a file every minute) I should do a "-age" command?

Jan, you mean that having modified a file:
a) Not the whole file is sent again, only the "modifications" made?
b) Between opening the file and closing it only "meta-data" (attributes) of
the file is sent and no reintegration is done ?
(I ask you this because I don't really understand what the "CML" count with
"cfs lv" means. Also I tested this with an editor, and changes are always
sent before closing. Probably because this editor "closes" the file after
writing to it the modifications, don´t know)

Thanks both. It is very helpful.

Saludos,
Juan Carlos


"Jan Harkes" <jaharkes_at_cs.cmu.edu> escribió en el mensaje
news:20040709044846.GC5211_at_delft.aura.cs.cmu.edu...
> Niraj already answered question #1, here is #2,
>
> On Tue, Jul 06, 2004 at 10:50:44PM -0300, Juan Carlos Schroeder wrote:
> > 2) I've read somewhere that Coda "replays" in the servers, the changes
made
> > in the client. Is this true? This means that it doesn't send the whole
file
> > every time it wants to reintegrate? (for example, every 1 or 2 minutes
if
> > I'm countinously making changes to the file)
>
> 2 things prevent this. First of all, updates are never sent back to the
> server as long as the file is still held open by some writer. Second, we
> perform optimizations on the reintegration log which eliminates
> certains sequences of operations.
>
> When a newly created file is removed before we reintegrate, we simply
> don't have to send anything. Similar for stores, if a store is pending
> but a new write comes in, the previously logged operation is optimized
> away.
>
> Jan
>
>
Received on 2004-07-09 23:47:03