Coda File System

Coda on clusters poll...

From: Troy Benjegerdes <>
Date: Sat, 1 May 1999 18:18:52 -0500 (CDT)
I've seen a couple of mentions of clusters on here, and I figured it was
time for a poll.

I'd like to know how many others are actively working on something
similiar so that we can trade information specific to clusters.

So, here's a poll:

1) Are you using Coda in a cluster/Beowulf type environment?
	If so, for what purposes? (home dirs, scratch space, redundancy)

2) Are you using Kerb5 with Coda?
	If so, for what reasons?

3) How many servers are you running, and how much data on each?
	Do you have any unusual partioning arrangements for RVM Data/Log?

4) Are there any problems/gotchas you would warn others to be carefull of?

And here are my answers:

1) I want to utilize Coda to contain all the user home directories, and
possibly a number of system binaries also (symlinking /usr/local to
/coda/usr/local comes to mind). I also want to evaluate Coda's performance
as a 'parrallel' file system. (i.e., a program needs to access the same
file on 8 machines at once... Multiple servers and caching might be an
improvement over one NFS server getting hammered)

2) I am using Kerberos 5 as the authentication mechanism. I am using
kerberos to take advantage of ticket passing using kerberized-rsh and

3) I am running 2 servers, each with a 9GB SCSI disk dedicated to /vicepa
(with a swap partition), a 4 GB IDE for /, swap, and RVM data, and a 2 GB
IDE for RVM log, and scratch space. I have ten clients (servers are also
clients), with 300 MB of venus cache.

4) Overflowing the client cache triggered a lot of bugs in previous
version of Coda, thus my use of 300 MB for cache. I have also had problems
with write-disconnected operation. It's better to stay strongly connected
and wait for a tar, than to run disconnected and have to clean up the
resulting mess.


| Troy Benjegerdes    |     |   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.   |
Received on 1999-05-01 19:21:40