Storage and compute usage policies¶

The partition limits and quota numbers on this page reflect direct observation of the clusters on 2026-07-25. On the clusters themselves, sinfo, scontrol show partition <name>, and quotas always show the current values.

Storage quotas¶

Once you exceed a soft limit we will ask you to reduce your usage; you cannot write beyond a hard limit. Note that the file-count limits are real quotas too — millions of tiny files will hit them long before the byte quota. Hopper has no machine-local scratch tier; see storage and backups for the full layout, and files on Easley-local scratch are deleted automatically after 180 days without access. To purchase additional storage please see our pricing spreadsheet.

The quotas command shows your quota usage. The number in an automated quota warning email covers only one group — you can be near your personal limit while project groups you belong to have plenty of room, and vice versa — so check the full quotas breakdown before deleting data. If the reported usage doesn't match any files you can actually find, see troubleshooting before deleting anything else.

Compute usage policy¶

To ensure that all research and class projects get their fair share of the clusters and to prevent any one group from using a disproportionate amount of resources, we utilize Slurm’s built-in job accounting and fairshare system. The cluster is a limited resource and Fairshare allows us to ensure everyone gets a fair opportunity to use it regardless of how big or small the group is. Your compute resource allocation is shared among everyone in the slurm account you select.

For more on Slurm accounts see Slurm accounting. Note that your slurm account is not the same as your CARC login account.

To see the predicted start time of your job based on your fairshare score, use the following command: squeue --start --job <job_id>

Partition limits¶

Easley¶

A job on general that does not request --time gets a default of 8 hours, not the maximum, and a job that does not request memory gets DefMemPerCPU — about 3.7 GB per requested CPU on general (bigmem and the GPU partitions set their own, higher values). Check scontrol show partition <name> for the partition you use.

Hopper¶

Hopper's general partition uses DefMemPerCPU=2938 (about 2.9 GB per requested CPU when --mem is unset). Access to the condo and lab partitions is restricted to their owning groups — check with your PI if you expect access to one.

Job time limits and extensions¶

Walltime limits vary partition by partition on both clusters — from 1 hour on Easley's debug to 10 days on some Hopper lab partitions — so never assume a blanket 48-hour limit; check your partition's limit in the tables above or with scontrol show partition <name>.

If a specific, already-running job needs more time than you requested:

• One-time courtesy extension — open a ticket with the job ID(s); support staff may extend a specific running job as a one-off courtesy.
• Permanent or repeated increases — changing a user's or project's runtime limits, or extending jobs as a pattern rather than a one-off, requires a written proposal justifying the increase, reviewed by the CARC director. Shared partitions keep their default limits to stay fair across all users, so anything beyond a single courtesy extension goes through the same justification-and-review process as any other allocation change.

Originally migrated from UNM-CARC webinfo; partition tables, quotas, and the extension policy reconciled 2026-09-01 against cluster state observed 2026-07-25 (CARC knowledge store). Spotted a problem? Open an issue or pull request.