"A month of sundays ago jaharkes_at_cs.cmu.edu wrote:"
> 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.

It looks like the code I have on my machine is 4.6.6, but I am guessing
until you show me the patch.  Depends on which machine I compiled.  I
thought the code was 4.7.0 from memory.  I haven't looked at it for a
month.

> 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.

Now I've got the compilation trick I might try that.  There were some
points in the patch that required a little thought and research.

> 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)

It's the machine that will fail (power, ventilator, ..), not the disk.
In those circumstances we will have an up to date backup not physically
present in the same room.

I also would have said that the obvious thing to do is to have a duplicate
something sitting right next to the server. Disks and processor. But
that's not the way the politics go. We can't even legitimately ask
for UPS because the maintenance department is supposed to supply secure
plugs (yellow ones) that never fail, oh yea. In fact they go down more
than the rest. I have all the servers plugged into normal stuff. But
as a result a spare server per lab is not biddable.  Hence the setup -
lab servers cross-backing each other across a switched 100MB net in pairs.

I am also chasing a kernel problem connected with tcp btw. Not present
in 2.0.25. Present in 2.0.36. Lockups with too fast tcp sends to
a socket from inside the kernel.


> l8r,
> 	Jan
> 

ptb