I spoke too soon.. :-(

I did that (cfs strong) and it worked for much longer.. than it crashed
again..
Same results as last time..except this time it took down the server and I
had to restart
the servers processes.

It is on the same hub 10/BaseT as the SCM.. I plan to move to switches, but
that should make
any difference as there are no collisions.

I am seeding the dir with 1000's of files initially so this will happen
infrequently, but it is annoying
and I am sure it is not healthy for the coda SCM to keep crashing like
this..

-Matt


-----Original Message-----
From: Jan Harkes [mailto:jaharkes_at_cs.cmu.edu]
Sent: Friday, June 01, 2001 10:05 AM
To: GiantWEB
Cc: codalist_at_TELEMANN.coda.cs.cmu.edu
Subject: Re: How do I make CODA clients NOT write-disconnected


On Thu, May 31, 2001 at 07:24:36PM -0400, GiantWEB wrote:
> yes the clients are getting connected fine but when I make a change to
> the /coda dir the only way other clients see the changes is if I run:
> cfs writereconnect (with tokens)
>
> My problem is the following.. I have 1.5Gigs of contetn I need to get
> to the server and replicated for each coda dir on each client. I have
> run tests and found that the content does not sync immiadly unless I
> invoke the above command.
>
> I need that changed as I need content to be the same on all webservers
> immediately when a change is updated to the Fileserver.
>
> I tried to copy the 1.5 gigs of content from a clients /main to /coda
> and it bails in the copy process.. WHY?

The bandwidth estimate is based on how quickly a server response is
received. When the server slows down when it is handling a lot of write
operations (due to RVM commits) this is perceived as low bandwidth. The
client eases the load on the server significantly by using
write-disconnected operation, in which case about 100 operations are
committed to RVM using a single transaction.

So in a way this is very nice behaviour because it keeps the server
'responsive' for all clients, no single client can hog the server.

However, when 'seeding' a volume with data, this can cause problems when
the amount of data that is copied is more than the size of the client
cache. In this case we can't log all writes and gently feed them back to
the server.

The solution you are looking for is 'cfs strong', it forces the client
to ignore bandwidth measurements, and unless there is a conflict or the
server is unavailable for more than 30 seconds all volumes should stay
connected.

Jan