It looks like the code to do this was never pushed into the v1.2 release
(although it is in the trunk). I have no idea what time frame you're
looking at, but if you need an updated ROMIO before 1.3 is available,
someone would need to bring over the changes and do a 1.2.6 release.
In v1.3, you'll be able to use the --disable-mpi-io option to configure to
completely remove any traces of MPI I/O support from the stock Open MPI
build (so that you could have an external ROMIO package).
On Mon, 11 Feb 2008, David Gunter wrote:
> We have a number of patches and files to be added to ROMIO to make it
> work with recent releases of the Panasas file system. We have reached
> a point where the stock ROMIO included in Open-MPI no longer works for
> what we need. I know that the version of ROMIO forged into the bowels
> of OMPI is a beast to try and patch or mend so that is something we
> won't attempt.
> Thus we have two choices here at LANL. Either we drop support and no
> longer provide OMPI to our user community and switch to MVAPICH2 for
> our only MPI on systems, or we can try and build OMPI against an
> externally maintained ROMIO.
> In an August 2007 email Jeff Squyres hinted that there is a way to do
> the latter:
> | Continual re-integration of ROMIO is definitely a logistics problem
> | that we have not solved. And it's becoming a bigger problem. :-(
> | Normally, we're quite open to accepting patches to Open MPI to put
> | them into the main distribution to ease the whole "millions of MPI
> | distros" issue, but with ROMIO it becomes quite difficult because we
> | have to source from Argonne's copy. Trying to manage what patches
> | need to go in is already quite difficult because:
> | - ROMIO is not on our release schedule
> | - OMPI adds its own integration patches to ROMIO
> | - All the OMPI developers have other work to do ;-)
> | Adding 3rd party patches in there for something that we already know
> | is complex and understaffed has unfortunately been a low priority. :-(
> | One thing that may make things a little better is that Brian recently
> | integrated some work onto the OMPI trunk that allows ROMIO to be
> | built outside of OMPI. Hence, if you have a standalone ROMIO, OMPI
> | can use it. I don't know the details (i.e., if you can still use
> | mpi.h / MPI_Request / MPI_Test / MPI_Wait like you can with the
> | default OMPI ROMIO integration) -- Brian will have to chime in here...
> | So I don't know what the real solution is here -- I'm just trying to
> | give some of the OMPI perspective. Suggestions are welcome.
> | Probably the best solution would be someone to volunteer to actually
> | spend the cycles to maintain ROMIO in Open MPI (I am pretty sure that
> | Brian simply does not have them)...
> | --
> | Jeff Squyres
> | Cisco Systems
> Since Brian no longer works on these issues I'm wondering if and how
> it is possible.
> David Gunter
> HPC-3: Parallel Tools Team
> Los Alamos National Laboraotry
> users mailing list