summaryrefslogtreecommitdiffstats
path: root/testpar/t_file_image.c
diff options
context:
space:
mode:
authormainzer <mainzer#hdfgroup.org>2017-04-06 23:11:21 (GMT)
committermainzer <mainzer#hdfgroup.org>2017-04-06 23:11:21 (GMT)
commit94c34773ceae5b30c4afb227d0385ebf4ab6ce28 (patch)
tree562c854493b7f45343ad61009cc4be31495398d8 /testpar/t_file_image.c
parent60167ae8753e48eb00be0dc015d3a476b8e02662 (diff)
downloadhdf5-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