Subject: Re: [MTT users] Patch to add --local-scratch option
From: Ethan Mallove (ethan.mallove_at_[hidden])
Date: 2008-09-18 10:45:13


On Thu, Sep/18/2008 10:11:19AM, Tim Mattox wrote:
> I Guess I should comment on Jeff's comments too.
>
> On Thu, Sep 18, 2008 at 9:00 AM, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> > On Sep 16, 2008, at 12:07 PM, Ethan Mallove wrote:
> >
> >> 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.
> >
> > In this case, my $0.02 is that it should be an error. --scratch implies a
> > --local-scatch, but I don't think the implication should go the other way.
>
> Yeah, I agree, especially if we call it --mpi-install-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?
> >
> > Mmm... good point. What if we name it what it really is:
> > --mpi-install-scratch? This also opens the door for other phase scratches
> > if we ever want them. And it keeps everything consistent and simple (from
> > the user's point of view).
>
> 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?

-Ethan

> >> 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?
> >
> > Hmm. I'm not quite sure how that would work -- "fastest" is a hard thing to
> > determine. What is "fastest" at this moment may be "slowest" 2 minutes from
> > now, for example.
>
> Yeah, I claim that auto-detecting file system speed is outside the
> scope of MTT. :-)
>
> > I'm looking at the patch in detail now... sorry for the delay...
> >
> > --
> > Jeff Squyres
> > Cisco Systems
> >
> > _______________________________________________
> > mtt-users mailing list
> > mtt-users_at_[hidden]
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> >
>
>
>
> --
> 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
> mtt-users_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users