Hello!

> 	The frontend servers will not have the same content. So even if
> user upload files through then, it will be no problem. The big
> opperation here will be the reading.

Sounds good. The need of personality switching still applies. You want to
let the web server process acquire Coda tokens via user supplied
passwords, while running with corresponding uids. Then setuid() will
effectively switch Coda personality, too.

> 	Coda has some space storage limitations? I was going to install
> it in a machine with RAID 5 (5 discs with 18G each) wich gives me 72G of
> storage space. Coda can't handle it?

Coda server can run out of metadata space (file owner, acls and similar)
when there will be lots of file objects. For now all of metadata has to be
mappable to the server process address space. In reality we cannot use
even all of 2G address space of 32-bits machines, it is slightly over 1G
that can be safely used. As Coda developers estimate metadata size to be
about 4% of the files size, it gives you about 25G file storage per server
process.

In reality the limit depends a lot on the average size of your files (that
determines the number of files). With files larger that "typical Unix file
size distribution" you can serve more data, and the other way around -
smaller files will fill up the metadata storage earlier.

It is no hard limitation as you can run multiple server processes on the
same server machine, but it makes the administration more burdensome.

You have to plan for 1G virtual memory per 25G file storage, too.

That is, for your 72G of data you would need 3G virtual memory.
On a host with 1G RAM you would need 2G swap.

Said that, you will probably never see the swap to be filled up.
The numbers above concern the worst case scenario that is unlikely to
happen (like "update on each file of a full file repository").
Anyway, you want to be on the safe side.

Good luck!
--
Ivan