Excellent points.
What about a slightly different approach that would allow us to be
exactly specific?
--scratch=dir1[,dir2[,dir3[,...]]]
And then in the INI file, have fields that indicate which scratch dir
you want them to use. For example, the fact that the OMPI MPI Install
plugin does a build is really a side-effect (not all MPI Install
plugins do builds). So we could have a field:
ompi_build_scratch = &scratch(1)
Or, heck, it doesn't even need to be a function of --scratch at all.
"ompi_build_scratch = <foo>" alone could be good enough.
On Sep 19, 2008, at 12:43 PM, Tim Mattox wrote:
I've also been thinking about this a bit more, and although
having the name match the INI section name has some appeal,
I ultimately think the best name is: --mpi-build-scratch, since
that is what it does. As Ethan mentioned, the actual MPI
install goes into --scratch. And on the other side of it,
the MPI Get also goes into --scratch. The --mpi-build scratch
is only used for untaring/copying the MPI source tree, running
config, make, and make check. The actual "make install"
simply copies the binaries from --mpi-build-scratch into --scratch.
As for names like local-scratch or fast-scratch, they don't convey
what it's used for, so should it be fast-for-big-files, of fast-for-
small-files?
Or similarly, "local" to my cluster, my node, or what?
I think mpi-build-scratch conveys the most useful meaning, since you
should pick a filesystem that is tuned (or at least not horrible) for
doing configure/make.
Unfortunately, I won't have time today to get the patch adjusted
and into svn. Maybe on Monday.
On Fri, Sep 19, 2008 at 11:23 AM, Ethan Mallove
<ethan.mall...@sun.com> wrote:
On Thu, Sep/18/2008 05:35:13PM, Jeff Squyres wrote:
On Sep 18, 2008, at 10:45 AM, Ethan Mallove wrote:
Ah, yeah, ok, now I see why you wouldl call it --mpi-install-
scratch, so
that it matches the MTT ini section name. Sure, that works for
me.
Since this does seem like a feature that should eventually
propogate to all the other phases (except for Test run),
what will we call the option to group all the fast phase
scratches?
--scratch
:-)
Seriously, *if* we ever implement the other per-phase scratches, I
think
having one overall --scratch and fine-grained per-phase
specifications
fine. I don't think we need to go overboard to have a way to say
I want
phases X, Y, and Z to use scratch A. Meaning that you could just
use
--X-scratch=A --Y-scratch=A and --Z-scratch=A.
--mpi-install-scratch actually has MTT install (using
DESTDIR) into --scratch. Is that confusing? Though
--fast-scratch could also be misleading, as I could see a
user thinking that --fast-scratch will do some magical
optimization to make their NFS directory go faster. I guess
I'm done splitting hairs over --mpi-install-scratch :-)
-Ethan
--
Jeff Squyres
Cisco Systems
_______________________________________________
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
_______________________________________________
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
--
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
--
Jeff Squyres
Cisco Systems
