Coda File System

Re: Problems with tar archives

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Thu, 11 Oct 2001 14:23:10 -0400
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.

Jan
Received on 2001-10-11 14:23:25