Sorry for the late reply, I unfortunately can't read all the traffic in
this list on a regular basis.

Given a sufficiently fast network or a sufficiently slow disk, you might be
able to write to the NFS server as fast as you can write to your own disk
(assuming you have one of those legato boards that buffer writes in a
RAMDISK). In the past I've found that a lightly loaded network and server
is usually enough to make the server faster.

The second point is that Coda uses session semantics, which means data is
propagated only when the file is closed. Hence reads and writes are as fast
as local file access. When shipping the file as it's closed, you get the
advantage of streaming data since you are potentially sending more than a
block.

Just some thoughts,

david.

ps, expirements I did on an older version of Coda showed the client disk to
be the bottleneck for transferring lots of files. I had been thinking I
could fetch multiple files in parallel from 3 servers, but the local disk
(and all the copying that was going on) made that infeasible.

david.

At 03:23 PM 4/28/98 -0400, Michael Callahan wrote:
>On Tue, 28 Apr 1998 thoth_at_purplefrog.com wrote:
>
>> "Peter J. Braam" <braam_at_cs.cmu.edu> ,in message
<Pine.LNX.3.96.980427150004.408
>> 	N-100000_at_carissimi.coda.cs.cmu.edu>, wrote: 
>> 
>> > When you are disconnected, there is NO network traffic (cool eh :) ) 
>> 
>>   Even when connected, it compiled at a speed that I couldn't remember as
>> being distinct from compiling to an NFS server (what I normally do).
>> 
>>   Ideally, I should be able to shotgun a gigabyte onto the local cache
(if it
>> were that big) at the speed of the local disk and then watch my network
light
>> turn on solid for the next half hour as the stuff gets synced to the
servers.
>> In the mean time I'd be compiling and/or editing the files I just created.
>
>Yes.  Right now, connected mode does write-through caching; work has been
>done to support write-back caching, but it's not in the mainline source.
>
>Michael
>
>
>
>