MPI_File_delete to delete a non-existing file

[wkliao]

When calling MPI_File_delete to delete a non-exiting file, the error class
MPI_ERR_NO_SUCH_FILE is expected to return. However, when I tested
2.0.1 release, I got MPI_SUCCESS returned instead.

[wkliao]

Forgot to mention that 1.10.3 release does return MPI_ERR_NO_SUCH_FILE correctly.
I believe the cause is from mca_io_ompio_file_delete() in file ompi/mca/io/ompio/io_ompio_file_open.c

Below is the diff between 1.10.3 and 2.0.1.

329,330c418,420
<     if (0 > ret) {
<         return OMPI_ERROR;
---
>     if (0 > ret && ENOENT != errno ) {
>   opal_output (1, "errno = %d %s\n", errno, strerror(errno));
>         return MPI_ERR_ACCESS;

[edgargabriel]

I'll look into this. The reason we made the change was because some benchmarks such as IOR use MPI_File_delete more or less as a collective operation, i.e. all processes that opened and closed the file also call file_delete. To make that case work where one process succeeds in deleting the file and the others not, we have to basically ignore the error code on the other processes (and keep in mind, file_delete does not take a communicator argument, so we can not just broadcast the return code to other procs).

1.10.3 was basically not able to execute IOR, while 2.x can. But I'll check whether I can find a solution to make it work in both scenarios.

[wkliao]

Thanks for the info. In my opinion, IOR should handle this issue, rather than OpenMPI. For example, IOR can use MPI_MODE_DELETE_ON_CLOSE mode when opening a file, so no explicit MPI_File_detele calls are needed.

FYI. I am a developer of Parallel-netCDF and a PnetCDF user reported a problem that lead me to this discovery. https://trac.mcs.anl.gov/projects/parallel-netcdf/ticket/20

PnetCDF relies on the MPI library underneath to report correct error codes and classes so it can find the correct corresponding netCDF error codes.

[edgargabriel]

I agree fundamentally with your position. I found the original reference, we changed the behavior last July

e380f8c

Anyway, will try to find a solution.

[edgargabriel]

A fix for this issue was committed to master and will be in the 2.0.2 release. Also just for the record, I was not able to reproduce the issue with the IOR benchmark that I saw last year (and which was the reason for the change in the first place).