On Tue, Sep/16/2008 12:07:31PM, Ethan Mallove wrote: > Nice! A few thoughts ... > > What happens if one uses --local-scratch, but leaves out the > --scratch option? In this case, I think MTT should assume > --scratch is the same as --local-scratch. > > Could the "local" in --local-scratch ever be misleading? > Couldn't a user ever use a mounted filesystem that's faster > than all their local filesystem? Should it be > --fast-scratch? > > For future work, how about --scratch taking a (CSV?) list of > scratch directories. MTT then does a quick check for which > is the fastest filesystem (if such a check is > possible/feasible), and proceeds accordingly. That is, doing > everything it possible can in a fast scratch (builds, > writing out metadata, etc.), and installing the MPI(s) into > the slow mounted scratch. Would this be possible? > > On Mon, Sep/15/2008 06:15:43PM, Tim Mattox wrote: > > Hello, > > Attached is a patchfile for the mtt trunk that adds a > > --local-scratch <dir_name> > > option to client/mtt. You can also specify something like > > this in your [MTT] ini section: > > local_scratch = &shell("echo /tmp/`whoami`_mtt") > > > > This local-scratch directory is then used for part of the --mpi-install > > phase to speed up your run. Specifically, the source-code of the > > MPI is untarred there, configure is run, make all, and make check. > > Then, when make install is invoked the MPI is installed into the > > usual place as if you hadn't used --local-scratch. If you don't > > use --local-scratch, then the builds occur in the usual place that > > they have before. > > > > For the clusters at IU that seem to have slow NSF home directories, > > this cuts the --mpi-install phase time in half. > > > > The downside is that if the MPI build fails, your build directory is out > > on some compile-node's /tmp and is harder to go debug. But, since > > mpi build failures are now rare, this should make for quicker turnaround > > for the general case. > > > > I think I adjusted the code properly for the vpath build case, but I've > > never used that so haven't tested it. Also, I adjusted the free disk space > > check code. Right now it only checks the free space on --scratch, > > and won't detect if --local-scratch is full. If people really care, I > > could make it check both later. But for now, if your /tmp is full > > you probably have other problems to worry about. > > > > Comments? Can you try it out, and if I get no objections, I'd like > > to put this into the MTT trunk this week. > > I'll test your patch soon. >
I was able to do an MPI get/install after applying the patch. I ran: $ client/mtt --local-scratch /tmp/foo --scratch /nfs/bar ... Which resulted in the build directory ending up in: /tmp/foo/.../src And the resulting installation ending up in the below directory via the DESTDIR macro passed to "make install": /nfs/bar/.../src The patch seems to do what it's supposed to do. -Ethan > -Ethan > > > > -- > > Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/ > > tmat...@gmail.com || timat...@open-mpi.org > > I'm a bright... http://www.the-brights.net/ > > _______________________________________________ > > mtt-users mailing list > > mtt-us...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users >