Attempt to open a file on a read-only NFSv4 mount fails

[Nathan_C_]

  We recently updated the NFS servers on our HPC cluster (Scientific Linux 6.7) to use NFSv4 from v3. Some programs compiled with ifort (16.0.2, 11.0, probably others) failed to open files on an NFSv4 filesystem mounted read only. The ifort run-time error was 43 (A pathname or file name given to an OPEN or INQUIRE statement was not acceptable to the Intel® Fortran RTL I/O system.). The file could be read by the same program compiled with gfortran 5.3.0.

  The fortran line was:

open (unit=iunit, file=filename(1:lfil), form='formatted', iostat=ios)

  The relevant strace output for ifort-compiled:

open("/path/to/file", O_RDWR|O_CREAT, 0666) = -1 EROFS (Read-only file system)
open("/path/to/file", O_RDONLY|O_CREAT, 0666) = -1 ENOTDIR (Not a directory)

and gfortran:

open("/path/to/file", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = -1 EROFS (Read-only file system)
open("/path/to/file", O_RDONLY|O_CLOEXEC) = 3

  Since "status" and "action" are unspecified in the fortran open(), the compiler is left to decide what is best. They both first try to open the file read-write, creating it if non-existent. When this fails due to being a read-only file system, ifort tries "open read-only, or create", while gfortran doesn't attempt the create. From what I can tell, the O_RDONLY|O_CREAT combination is POSIXly legal, but is not being handled well by the NFSv4 parts of kernel  2.6.32-573.18.1.el6.x86_64. 

  A quick work-around is to set status='old' and/or action='read' in the fortran open(). The first will not try to open with O_CREAT, while the second succeeds immediately with O_RDONLY.

  Does the O_RDONLY|O_CREAT combination ever make sense? Should ifort-compiled programs simply skip the O_CREAT flag when falling back from an EROFS? What's the best way to report this to the ifort and NFS maintainers?

[Edit: Submitted as bug to RH: https://bugzilla.redhat.com/show_bug.cgi?id=1329769]

Thanks,

Nate Crawford