On 9 Jul 2003, Dick Kniep wrote:

> Please comment!

Hello Dick,

here you are :)

> > Anyway a native Coda client is better.
>
> Yeah, but without a harddisk, it is pretty useless!

It can be useful or useless depending on the needs, policies and
usage patterns.

> 1. To use a Coda client for remote boot on a thin client without a
> harddisk is hard to establish, and unreliable, because if we establish

You would need a lot of RAM to achieve reasonalble gain from caching.

> 2. To use NFS from Coda gives me the following problems: We'll have the

I would not consider that approach being feasible at all. Keep you with
one filesystem.

> 3. Do accept a harddisk on the clients. In that case, we could use the
> harddisk as the local cache, and the problems are solved. However, the
> real reason behind the remote boot, is the fact that management of many
> clients is so much easier, because the configuration is maintained
> centrally on the server. But this means that we still have to solve the
> remote boot problems (with an INITRD which contains Venus etc.)

Have you considered local boot, while optionally from network for
(re)setting up the local system? It is quite common and efficient
approach, especially when the local part of the system is small.

> So I'm drawing the conclusion that hardware RAID solutions should be the
> way to go? (Remember we are trying to solve Single Point of Failures) We

What do you mean? RAID is in no way a distributed filesystem, why do
you mention it in the same contents as NFS and Coda?

> should implement a number of systems with LVS, and connect a RAID
> cabinet to the different systems. The reliability will be less, but I

To multiple NFS servers or to all clients?

> think it is probably not feasible to get the Coda/NFS solution working
> in a reliable way without a lot of programming.

If you mean Coda over NFS, then just forget it.

Best regards,
--
Ivan