Steve, 

What's in your /usr/coda/etc/vstab?

Are you using a LOG file or a raw log partition, same for data on the
server?  What is the size of that data file?

Things are slow (and a solution is in the making) but what you tell us is
terrible.

- Peter -


On Sun, 8 Feb 1998, Steven N. Hirsch wrote:

> 
> 
> On Sat, 7 Feb 1998, Jim Doyle wrote:
> 
> > 
> > Tonight, as a respite from my DCE hacking, I decided to give a go at
> > porting Coda to Linux/Alpha. I am running Redhat 5.0 (2.0.32 kernel) on
> > several fairly beefy Alpha servers.
> > 
> > There are 64-bit safety hazards throughout Coda. I dont believe any of
> > them will be difficult to fix - its just really busy work. For those
> > of you that dont understand this:    A virtual memory address (i.e. a 
> > void * or an anything *) is a 64 bit integer. This corresponds to
> > the "unsigned long int" datatype. On non-AXP machines (Intel, SPARC, PPC),
> > a virtual memory address is 32-bits, and can fit into an "int" type.
> > 
> > Now would be a good time (or, at the next Coda src freeze point) to
> > go make Coda 64-bit safe. As I said its just alot of busy work.
> > 
> 
> I will gladly volunteer as a tester for anything you can come up with.
> I'd really like to participate in the coding, but the sheer volume of
> source is absolutely overwhelming, and I'm not aware of any "roadmap"
> documentation :-(.
> 
> Under Intel Linux, I've yet to get through my basic networking test:
> 
> - Copy linux source tree to coda volume
> - Do 'make mrproper'
> - Do 'make xconfig'
> (etc.)
> 
> Copying the source to the server takes almost an hour (and, yes, I do have
> the metadata and log on their own partitions).  This is incredibly slow..
> 
> Make mrproper fails on the first pass because it still thinks that
> directories it has just cleaned of files are busy.  
> 
> If I clean by hand, and attempt xconfig it fails with random corrupted
> files.
> 
> Smaller applications will build (most of the time), but something's broken
> somewhere.  Any ideas where to look?
> 
> Steve
> 
>