[mpich-discuss] reading from a read only directory
robl at mcs.anl.gov
Tue Dec 3 10:20:06 CST 2013
On Sat, Nov 30, 2013 at 08:35:39AM -0600, Jed Brown wrote:
> Geoffrey Irving <irving at naml.us> writes:
> > It's not an issue for me personally anymore: chmod +w . is fine, and
> > symlinks would also solve the problem. The question was more about
> > the motivation for the code and whether it's an issue anything thinks
> > is worth fixing (or fixable at all). That and Jed asked me several
> > times to start the thread. :)
> It's not intuitive and does not appear to be documented. Reading from a
> read-only directory is a reasonable thing to try and people should not
> have to wait through a queue to find out that it doesn't work.
Mea culpa. MPI_File_read_ordered is implemented in "stupid mode"
right now, and no one ever complained -- we don't pay much attention
to shared file pointers. Tell me more about how you are relying on
ordered mode, please.
The technical issues here: the shared file pointer and ordered mode
collectives keep as global state the location of the shared file
pointer. Where does it keep this state? Why, in the file system of
course. Because using a file system as a message-passing medium is
exactly what file systems are good at.... uh, well, maybe not, but
it's the most portable option.
You can also do this with RMA windows (Rob Ross and I published some
papers on this topic back in 05 and 06). Has a few drawbacks but it's
got to be better than the file system.
Even without the RMA windows, we can still do a better job for ordered
mode with MPI_SCAN -- it's just we need some globally-available place
to get the old shared file pointer value and stash the new one.
In user-space, you'll outperform MPI-IO implementations if you manage
the offset yourself.
I wrote a little ordered mode shim you can link into your program.
Looks like I last seriously did anything with it back in 2008 ? I
cleaned up some of the warnings and made it use MPI_Count (remove
HAVE_MPI_TYPE_SIZE_X from the makefile if you're on an old system).
Caveat: I think the last time I ran this code was on Argonne's Blue
Gene /L. Bear in mind the adage about tested code and broken code.
Mathematics and Computer Science Division
Argonne National Lab, IL USA
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 18170 bytes
Desc: not available
More information about the discuss