> 
> 1) I used gcc 2.8.something (probably 0 as I like 0). and all of the
>    changes I made were to avoid compile errors, not compile warnings.

Allright, I'll probably have to try installing both gcc 2.8.x and a recent
glibc library, as they both seem to be quite picky for compiling and
running coda.

> 2) In particular, wrongly typed nulls seem to be a no-no under gcc 2.8.*.
>    But they were easy to catch. Just tedious.

That's ok, I'll believe I still have your patch somewhere and can fix
those untyped NULL's.
 
> 3) I compiled against linux 2.0.25, which maybe explains why you didn't have
>    to do one of the includes that I did have to do. Clearly an autoconf case.
>    Testing for time structures is a standard thing in autoconfs. Inclusion
>    orders change.

That might also be a libc5 issue. I've made a note to look into adding the 
rules to autoconf.

> uh ..  and the raid5 over nbd is undergoing production tests, as is (in
> a mild way) a 1GB coda 4.6 server.

Coda 4.6? The 4.6.3 is suffering from rpc2 buffer overflows, which caused 
some grief here. The 4.6.5 fixed an LWP locking problem which occasionally
allowed two threads to run through the same critical region. And any version
before 4.7 has the potential of severely corrupting directory data structures.

On the other hand, we do have some 4.6.7 servers running now which have been
up for over 29 days, seeing daily (light) usage. So for mild production 
testing it might be ok to use a 4.6 server, although I'm more trusting the
5.0 release.

> Yes and no - to do a multiway feed via raid5 over the net you have to
> do some tricks.  I am just testing a straightforward raid5 mirror to a
> device on a co-server from a server that is feeding nfs clients with the
> composite device. It's only intended to provide an uptodate backup
> image of the state (modulo an e2fsck) in case we lose the main server.
> It should be accurate to 30s.  (the arrangement is actually symmetric -
> each server backs up the others play area, but never mind). If one
> actually goes down we have to e2fsck and ip-alias for the missing one by
> hand.

So your point of failure is the nfs server exporting from the raid5 to the
clients. Why isn't just having an external chain of scsi disks easier for
this type of setup? (switch the IP & the scsi cable over to the hot-spare)

> Regards
> 
> ptb

l8r,
	Jan