(Illustration by Gaich Muramatsu)
On Thu, Oct 11, 2001 at 06:19:37PM +0200, Matthias Teege wrote: > On Thu, Oct 11, 2001 at 10:44:28AM -0400, Jan Harkes wrote: > > ?? I don't see anything being gone. The few ENOENT errors look like > > stat operations to check whether the destination of a rename really > > doesn't exist. I also see that you're running write-disconnected, and > > Hmm, the write-disconnected I see to but it wasn't my intention. Both > servers are connected with a fast network and I don't want to use the > disconnected mode between these servers. How can I turn this mode off. > Cfs wr isn't the right one? Or is this because the cvsup is faster tha > coda can write the files over the network? Actually it is because the servers are pretty slow on the many directory operations. The bandwidth estimation is influenced by the slow server responses and the client kicks in write-disconnected mode. Reintegration is actually more efficient even for the servers, because we need only one RVM transaction for all operations instead of a transaction for each single operation. So this backing off both unloads the servers, and makes server-side processing more efficient. The problem is that while a client is write-disconnected it has more chances of getting some inconsitent state, and there is a higher likelyhood of hitting obscure bugs. 'cfs strong' makes the client ignore bandwidth estimates, so it should in most normal situations keep the client in connected mode. > Probably not, > du -shk ports > 99M ports > > but a lot of small files. Then you could still be hitting the file limit, Coda assumes an average of 24KB per file, so a 300MB cache maxes out around 12000 files. JanReceived on 2001-10-11 14:23:25