(Illustration by Gaich Muramatsu)
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. JanReceived on 2001-06-01 11:22:51