cc_staff
22
edits
Storage and file management: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 32: | Line 32: | ||
* <b>PROJECT:</b> The project space has a significantly larger quota and is well adapted to [[Sharing data | sharing data]] among members of a research group since it, unlike the home or scratch, is linked to a professor's account rather than an individual user. The data stored in the project space should be fairly static, that is to say the data are not likely to be changed many times in a month. Otherwise, frequently changing data, including just moving and renaming directories, in project can become a heavy burden on the tape-based backup system. | * <b>PROJECT:</b> The project space has a significantly larger quota and is well adapted to [[Sharing data | sharing data]] among members of a research group since it, unlike the home or scratch, is linked to a professor's account rather than an individual user. The data stored in the project space should be fairly static, that is to say the data are not likely to be changed many times in a month. Otherwise, frequently changing data, including just moving and renaming directories, in project can become a heavy burden on the tape-based backup system. | ||
* <b>SCRATCH</b>: For intensive read/write operations on large files (> 100 MB per file), scratch is the best choice. However, remember that important files must be copied off scratch since they are not backed up there, and older files are subject to [[Scratch purging policy|purging]]. The scratch storage should therefore be used for temporary files: checkpoint files, output from jobs and other data that can easily be recreated. <b>Do not regard SCRATCH as your normal storage! It is for transient files that you can afford to lose.</b> | * <b>SCRATCH</b>: For intensive read/write operations on large files (> 100 MB per file), scratch is the best choice. However, remember that important files must be copied off scratch since they are not backed up there, and older files are subject to [[Scratch purging policy|purging]]. The scratch storage should therefore be used for temporary files: checkpoint files, output from jobs and other data that can easily be recreated. <b>Do not regard SCRATCH as your normal storage! It is for transient files that you can afford to lose.</b> | ||
* <b>SLURM_TMPDIR</b>: While a job is running, <code>$SLURM_TMPDIR</code> | * <b>SLURM_TMPDIR</b>: While a job is running, the environment variable <code>$SLURM_TMPDIR</code> holds a unique path to a temporary folder on a fast, local filesystem on each compute node allocated to the job. When the job ends, the directory and its contents are deleted, so <code>$SLURM_TMPDIR</code> should be used for temporary files that are only needed for the duration of the job. Its advantage, compared to the other networked filesystem types above, is increased performance due to the filesystem being local to the compute node. It is especially well-suited for large collections of small files (for example, smaller than a few megabytes per file). Note that this filesystem is shared between all jobs running on the node, and that the available space depends on the compute node type. A more detailed discussion of using <code>$SLURM_TMPDIR</code> is available at [[Using_$SLURM_TMPDIR | this page]]. | ||
==Project space consumption per user== <!--T:23--> | ==Project space consumption per user== <!--T:23--> | ||