Coda File System

Corrupt files [Re: coda-4.3.13 src: 64-bit safety problems]

From: Peter J. Braam <braam_at_cs.cmu.edu>
Date: Sun, 8 Feb 1998 21:35:22 -0500 (EST)
I don't quite understand what is going on with the clean "by hand" and
make xconfig stuff -- but I am extremely keen to understand this bug.

Can I get more details please.

- 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
> 
> 
Received on 1998-02-08 21:37:09