You should probably address many of your questions to the Beowulf list
(I'd advise searching through their archives and/or Googling around
first -- diskless compute nodes is something that has been discussed
many times; there are several projects available that do this; check
out Warewulf -- http://www.warewulf-cluster.org/ -- for example).
One question you might want to ask yourself is why you'd want to be
compiling out on your nodes. Many sites only allow compiling on the
head node where you have full set of tools, plenty of disk space, etc.
If you're building a compute farm (as opposed to a compile farm), there
may be little reason to allow compiling out on the nodes. Hence, you
really only need run-time stuff out on the nodes.
As for LAM, LAM basically needs parts of the bin/, lib/, and etc/
directories from its $prefix to be available on the nodes (and if you
compiled LAM statically -- the default -- then even the .a's don't need
to be out on the nodes). This does *not* mean, however, that the files
need to physically reside there (on disk or in RAM or otherwise). The
LAM executables and libraries are typically only used at the start and
end of a job; so if you make them available via NFS (for example),
you'd pay a little startup cost at the beginning and end of the job,
but then you'll have that much more RAM available for your ramdisk and
the actual job that is running out there. See the LAM FAQ for some
suggestions here.
In short: not having the LAM executables physically on the nodes should
not affect your job performance much (assuming that your parallel jobs
are sized large enough that a small startup penalty won't matter).
On Oct 17, 2005, at 9:04 PM, seven replay wrote:
> (having said that...)
> Hi there.
> I'm thinking of building Lam/Mpi on diskless nodes.
> The distro that I'm going to build on is one that I
> will make myself (using LFS's book). Now, the
> rootdirectory that I will be making will be working on
> the RAMDISK of the nodes. Having small amount of ram (
> alltho I could buy more I don't want to waste it) i
> would like to make this root dir. so small as I can.
> That means taking things that the nodes wont be
> using.(ooo.. and I mean taking everthing that is
> unnecessary to a machine with no keyboard and no
> mouse). But ofcourse leaving gcc, binutils and glibc.
>
>
> Before asking: Here's the plan.
>
> I want to make the filesystem a ram filesystem(root
> dir. on chip). So that means the compiling time would
> be faster ( when having space on the ramdisk to
> compile ). Putting unneeded stuff would make things go
> wrong. But still there are some utils that should be
> there to make
> the machine work as it should. But those utils
> woulden't be working when the machine is Compiling. So
>
> at some point they become "unwanted software".
> So after getting this, It came to me like this:'How
> about building the most wanted software for to be
> living on the Ram Disk of the node and the unwanted
> software on the server.'.
> So yeah -it's like saying- I will put the needed
> software for lam nodes on the ramdisk because lam
> needs them there(faster). And I will put the others on
> NFS-Server because my Network Top. is slow.(slower)
>
> That was the TAO.: No for the questions :p????:p
>
> I was thinking of only putting gcc and glibc and
> binutils and lam - required on ramdisk- But what
> software should be there with the Lam ? :p
>
> What should be on the server ? Would bash shell be a
> good one to stand on the server or it's best to be on
> the machine ? :p
>
> What about networking, mounting utils , textutils ,
> more on coreutils, the /dev directory? :p
>
> Inonequestion : ?When lam is Working What Files And
> Programs is it Using? --Not when it's starting --Not
> when it finishs
>
> There.
> Oh and I'm a newbie:p haha!!
>
>
>
>
> __________________________________
> Start your day with Yahoo! - Make it your home page!
> http://www.yahoo.com/r/hs
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
|
