diff options
author | mainzer <mainzer#hdfgroup.org> | 2017-04-06 23:11:21 (GMT) |
---|---|---|
committer | mainzer <mainzer#hdfgroup.org> | 2017-04-06 23:11:21 (GMT) |
commit | 94c34773ceae5b30c4afb227d0385ebf4ab6ce28 (patch) | |
tree | 562c854493b7f45343ad61009cc4be31495398d8 /testpar/t_file_image.c | |
parent | 60167ae8753e48eb00be0dc015d3a476b8e02662 (diff) | |
download | hdf5-94c34773ceae5b30c4afb227d0385ebf4ab6ce28.zip hdf5-94c34773ceae5b30c4afb227d0385ebf4ab6ce28.tar.gz hdf5-94c34773ceae5b30c4afb227d0385ebf4ab6ce28.tar.bz2 |
Checkin of fix for CGNS bug
(https://jira.hdfgroup.org/browse/HDFFV-10055).
Briefly, in H5C_collective_write() in H5Cmpio.c,
the metadata cache attempts to perform a collective
write of metadata cache entries.
This worked fine as long as all processes had at
least one entry to write.
However, when the process has no entries, the
function tries to participate in the collective write
by calling MPI_File_set_view(),
MPI_File_write_all() and then MPI_File_set_view()
again, to match the calls in H5FD_mpio_write().
After pull request 183, the CGNS test benchmark_hdf5
started failing. On investigation, I determined that
the failure occurred in the first call to MPI_File_set_view()
in the "no data to write" path through H5C_collective_write().
Note that pull request 183 did not create the problem,
it only exposed it. The bug can be observed after pull
request 182 if one executes the CGNS progam
src/ptests/benchmark_hdf5 with 90 processes.
The problem appears to have been that the calls to
MPI_File_set_view() in H5C_collective_write() and
H5FD_mpio_write() were using different values for the
info parameter. I patched the problem by adding a
MPI specific VFD call allowing me to get the MPI_Info
used in H5FD_mpio_write() for use in
MPI_File_set_view() calls in H5C_collective_write().
Tested serial & parallel, debug & production on
Jelly.
Diffstat (limited to 'testpar/t_file_image.c')
0 files changed, 0 insertions, 0 deletions