Changes to Scratch Storage Policies

We are updating how we describe and manage scratch storage to keep our systems fast, reliable, and fair for everyone.

Following good data practices makes scratch more performant and more useful for all users. By keeping master copies of important data in backed‑up storage, staging only the inputs and outputs you need for active jobs into scratch, and promptly moving valuable results back to a persistent location when your work completes, you help keep scratch fast, responsive, and available for high‑throughput workloads across the system.

To support this, we’ve updated our scratch documentation with clearer guidance and policies, including:

• An emphasis on scratch as temporary, high‑performance workspace, not long‑term storage.
• Clearer explanation of purge behavior and age limits (including that files may be removed at any time after they become eligible).
• Removal of legacy “purge warning email” language; users should no longer expect email notifications before files are purged.
• Explicit guidance that using tools like touch or other methods to defeat purge mechanisms is a violation of Acceptable Research Resource Use.
• Practical tips and examples for staging data into scratch, monitoring file ages with tools such as purgelist , and moving important results back to Data Depot or Fortress.

Scratch filesystems are engineered for capacity and performance and are not protected by backup technology; some types of failures can result in permanent data loss. If losing a file in scratch would significantly impact your research, that file should have a current copy in a more durable storage location such as Data Depot (for active data) or Fortress (for long‑term archival).

You can review the updated scratch storage guidance here: https://www.rcac.purdue.edu/policies/scratchpurge

If you have questions about how to adapt your workflows or where to store particular data, please contact us at rcac-help@purdue.edu and we’ll be happy to help.