SCR caches checkpoint data in storage on the compute nodes of a Linux cluster to provide a fast, scalable checkpoint / restart capability for MPI codes.
In a case where SCR is directed to write to /autofs, the run throws an error from flock() when access the halt file:
SCR v3.0.0: rank 0 on crusher180: NPROCS=8
SCR v3.0.0: rank 0 on crusher180: NNODES=1
SCR v3.0.0: rank 0 on crusher180: Stopping all async flush operations
SCR v3.0.0 ERROR: rank 0 on crusher180: Failed to acquire file lock on /autofs/proj/user/job/.scr/halt.scr: flock(23, 1) errno=524 Unknown error 524 @ /path/to/scr/src/scr_io.c:173
SCR v3.0.0: rank 0 on crusher180: scr_fetch_latest: return code 1, 0.000708 secs
This flock() error does not show up if using the parallel file system.
Running SCR on an NFS file system is known to be problematic. The library and the commands share some common files and they use file locking to control concurrent access. File locking on NFS is not always supported.
If the underlying file system supports locking with fcntl, it may help to switch lock methods with -DSCR_FILE_LOCK=fcntl:
In a case where SCR is directed to write to
/autofs, the run throws an error fromflock()when access the halt file:This
flock()error does not show up if using the parallel file system.Running SCR on an NFS file system is known to be problematic. The library and the commands share some common files and they use file locking to control concurrent access. File locking on NFS is not always supported.
If the underlying file system supports locking with
fcntl, it may help to switch lock methods with-DSCR_FILE_LOCK=fcntl:https://scr.readthedocs.io/en/v3.0/users/build.html#cmake