Filesystem
The Filesystem¶
The cluster exposes several distinct storage areas, each with a different purpose, performance profile, and retention policy.
| Path | Purpose | Quota | Snapshots | Notes |
|---|---|---|---|---|
/home/your_username |
Personal files, source code, scripts | ~200 GB (varies) | ✅ ~7 days | Shared NFS; convenient, but slow for heavy job I/O |
$SLURM_TMPDIR |
Temporary job I/O, for intensive I/O | Varies with node | ❌ None | Fast local disk on the compute node, no network overhead; purged when the job ends |
/projects |
Shared group data, software builds | Varies | ❌ None | Shared NFS; ask your PI for access |
/farmstorage, /farmstorage2 |
Bulk shared datasets | Varies | ✅ ~7 days | Shared NFS |
/astro |
astro group data |
Varies | — | Shared NFS, group-restricted |
Snapshots are not backups¶
The shared storage runs on ZFS with automatic snapshots: 24 hourly plus 7
daily, giving roughly a one-week recovery window on /home and
/farmstorage.
This protects you against the ordinary disaster — an accidental rm -rf, a
script that overwrote its own inputs, an edit you want to undo. It does
not protect you against loss of the storage system itself, and there is
currently no off-site backup. Keep source code in a Git repository hosted
elsewhere, and keep your own copies of results you cannot regenerate.
/projects has no snapshots at all.
Unlike /home and /farmstorage, the
/projects filesystem is not snapshotted.
Deletions there are immediate and unrecoverable. Treat it as working
space for data you can regenerate, not as the only home for anything
irreplaceable.
Recovering a deleted file¶
Snapshots live under .zfs/snapshot/ on the storage server, but that path
appears empty when read over NFS from the login node — you cannot browse
or restore your own files directly. Recovery has to be done by an
administrator on the storage server.
If you delete something you need back, email admins@lcm.mi.infn.it promptly — hourly snapshots roll off after a day and dailies after a week. Include the full path and roughly when the file was last known good.
Slurm gives every job a private directory on the compute node's local disk
— for example /slurmtmp/1012526 — and wipes it when the job
ends, whether it succeeded, failed, or was cancelled. Use it for active
job I/O, then copy anything you want to keep to /home or
/projects before your script exits.
There is no /scratch and no /project
Guides written for other HPC sites often refer to a shared /scratch
filesystem, or to /project in the singular. Neither path exists here.
The equivalents are $SLURM_TMPDIR for per-job temporary space and
/projects for shared group storage.