...
| Note |
|---|
As of July 1st, 2016, files on |
...
the cluster-wide /nfsscratch filesystem are subject to deletion 60 days after they were created. Policy for node-specific /localscratch filesystems is independent of this. |
User Scratch Space
Each compute node has its own local scratch filesystem. Users may read from and write to this using their own exclusive directory at /localscratch/Users/<HawkID>.
...
On /localscratch, the allowed file lifespan is 30 days after the file was last accessed, and a where each file's age is the time elapsed since its access timestamp ("atime"). An automated cleanup process will run runs periodically on each node to delete files whose atime has reached the maximum lifespan. It is also expected that large amounts of data put on /localscratch are cleaned up at the end of a job. Otherwise, the node can become unavailable and will have its /localscratch cleaned entirely, irrespective of time stamps, to make it available again
If your job writes data to /localscratch, please retrieve everything you need and remove unneeded files as the last part of the job, because it's difficult to access that same compute node after a job exits! A compute node can become unavailable if its /localscratch filesystem becomes too full. If that happens, all files will be removed from /localscratch without considering lifespan in order to restore the compute node to service.
/nfsscratch
On /nfsscratch, the allowed file lifespan is 60 days after first being written filesystem, and a where each file's age is the time elapsed since its creation timestamp ("crtime") which is tracked on the fileserver. An automated cleanup process will run periodically on the server to delete files whose crtime has reached the maximum lifespan.
| Note |
|---|
| Altering or duplicating files solely to circumvent the scratch cleanup process is against policy. Please make legitimate use of scratch filesystems, then move your intermediate and final results to stable storage in accordance with policy. |
Please contact research-computing@uiowa.edu with any questions or for assistance with this.
Local or Shared Scratch?
- Multiple jobs The compute node running your job might be running on your job's node. These other jobs (belonging to you or other users). So Multiple jobs can compete for local storage I/O, causing contention independent of /nfsscratch. Only a job with exclusive access to a node can expect the full performance potential of the node's local storage.
- A parallel job running on multiple nodes typically shouldn't use filesystems local to any of its nodes. Even if you're writing your own MPI instead of using an off-the-shelf application, you can expect better performance if you collate results in memory via message passing and write your result to the shared filesystem. Consider local disk primarily as a structured alternative to swap.
- If your job places partial results on /localscratch but fails to handle them for any reason (logic error, eviction, crash, etc.), you won't have access to these anywhere else and they will be difficult to recover.
- As always, please test a few jobs first if you are unsure before submitting a large batch.
File Timestamps
- modification time (mtime): This is the time the contents of the file were last modified, for example, by editing it. The modification time can be seen with
ls -l file
...