What about a slightly different approach that would allow us to be
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-
> 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.mallove_at_[hidden]> 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
>>>> 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
>>> Seriously, *if* we ever implement the other per-phase scratches, I
>>> having one overall --scratch and fine-grained per-phase
>>> 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
>>> --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 :-)
>>> Jeff Squyres
>>> Cisco Systems
>>> mtt-users mailing list
>> mtt-users mailing list
> Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
> tmattox_at_[hidden] || timattox_at_[hidden]
> I'm a bright... http://www.the-brights.net/
> mtt-users mailing list