No we do everything via NFS at the moment. Using a big ramdisk would cut
into why all the machines have so much memory and CPU's. Basically the
idea is that all CPU cycles are local and all data is foreign. The
approach to this seems to follow either SGI or Sun ways of doing
diskless clients. I like the Sun way of doing it (with each client
getting its own tree) versus the SGI where most is common with the
server and clients need a rebuild if server code changes.
On Wed, 2003-07-23 at 17:40, Paul Iadonisi wrote:
On Wed, 2003-07-23 at 18:41, Stephen Smoogen wrote:
[snip]
>
> Actually it is the opposite of want I need. The clients are usually
> multi cpu/ large ram machines/ etc with the server being not much at
> all.
>
> I think that LTSP servers 90% of most diskless environment needs.. I
> just end up in the 10% where the machines are diskless for programatic
> needs but the work must be done on the workstation (Lets just say a lot
> of the work maxes out a 2-4 CPU workstation.)
Ah, I see. So it sounds like a job for openMosix (with node/cpu
affinity), Compaq/HP's SSI, or maybe a customized LTSP config that
creates a really big ramdisk to hold a full OS instead using NFS
mounts. Hmm, if you use the big ramdisk approach, then it seems like
not so big a change from the usually LTSP config, though I wouldn't call
it LTSP at that point, but instead 'diskless-client' or something
similar.
I think most of what wrote might still apply. It could be made as
some config option. Or even if it's separate, they are related enough
that I might be able work on both.
--
Rhl-devel-list mailing list
Rhl-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/rhl-devel-list --
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #)
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --