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