User scratch space
All users have /nfsscratch/Users/HawkID available to them via our ZFS/NFS file systems. It is set to be read/write/executable for the user only. This user space is located on /nfsscratch/$Username on all nodes. There is also a local scratch space available (/localscratch/$USER) on all nodes if local disk scratch is needed. There is a cleaning policy in effect on all scratch volumes where, if the files have not been accessed in 30 days or more, they will be deleted.
Cleanup policy
The cleanup script currently runs every day looking for files that have not been accessed in the last 30 days. Basing this on access time works well in the case where files are being generated by computations on scratch and left there. However, in the case where files are moved to the scratch system from another source, the time stamps of the files from the source need to be considered.
There are 3 time stamps that get put on a file:
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
change time (ctime): This is the time the metadata of the file was last changed. An example of this would be moving a file to a different directory. The change time can be seen with
ls -lc file
access time (atime): This is the time the contents of the file were last accessed, for example, by viewing with 'less'. The access time can be seen with
ls -lu file
It is possible for the 3 timestamps to be different for the file. The most important point to remember, in light of the cleanup script using access time, is that the timestamps (including access time) may be carried over from an archive if the files are being extracted from one. Most archive utilities will maintain the timestamps, either by default or optionally. This includes using archive mode ('-a') with either 'cp' or 'rsync'. If the timestamps from the source are carried over then it could lead to a situation where your extracted files are deleted by the clean up script before 30 days have elapsed. This is because the access time stamp (carried over from the archive) is older than what you might be expecting.
There are several ways to update the timestamps but the easiest would be to use the 'touch' command. Even using that, there could be several ways to call it depending on the directory structure of the files you are extracting/moving/copying. One example would be to run the 'find' command in the top level directory of your newly extracted files.
Example of updating timestamps of extracted files
find /nfsscratch/Users/gpjohnsn/extracted/ -type file -print0 | xargs -0 touch
After running the above, the files will have the current timestamp. It is possible, if desired, to update only the access timestamp by using the '-a' option to touch in the above command.
find /nfsscratch/Users/gpjohnsn/extracted/ -type file -print0 | xargs -0 touch -a
Please contact hps-sysadmins@iowa.uiowa.edu if you need assistance with this.