...
MedicineBow uses the Data (VAST) filesystem configured with a 190 TB SSD tier for active data and 1.2 PB HDD capacity tier for less-used data. The system policy engine moves data automatically between pools (disks and tiers). The system will automatically migrate data down to HDD based on file age. MedicineBow has several spaces that are available for users to access described in the table below.home/home/username ($HOME)3 petabytes NVMe system, including advanced block-based data deduplication which will give an expected 6 PB of overall capacity. The cluster has several storage locations available for users and allocated for specific purposes. These storage spaces are described below.
home - /home/$USER/
Space for configuration files and software installations. This file space is intended to be small and always resides on SSDs. The /home file space is snapshotted to recover from accidental deletions.
alias:
$HOME
project - /project/project_name/$USER/
[username]
Space to collaborate among project members. Data here is persistent and is exempt from purge policy. The /project file space is snapshotted to recover from accidental deletions.
gscratch - /gscratch/$USER/
username ($SCRATCH)
Space to perform computing for individual users. Data here is subject to a purge policy defined below. Warning emails will be sent when possible deletions may start to occurdeletions are expected. No snapshots.
alias:
$SCRATCH
Global Filesystems
Directory Name | Quota (GB) | Snapshots | Backups | Purge Policy | Additional Info |
---|---|---|---|---|---|
home | Yes | No | No | Always on SSD | |
project | Yes | No | No | Aging Data will move to HDD | |
gscratch | No | No | Yes | Aging Data will move to HDD |
Snapshots vs Backups
Snapshots are a point in time reference of a specific filesystem, that can be referenced after changes are made. The data stays on the same storage system. This data would not be recoverable if there is an issue with the storage system.
...
File spaces within the MedicineBow cluster filesystem may be subject to a purge policy. ARCC reserves the right to purge data in this area after 30 to 90 days of no access or from creation timesubject to purge policy. Before performing an actual purge event, the owner of the file(s) will be notified by email several times for files that are subject to being purged.
Additional information summarizing ARCC’s storage policy is available here.
...
The memory filesystems can really enhance the performance of small I/O operations. If you have a localized single node I/O jobs that have very intensive random access patterns, this filesystem may improve the performance of your compute job.
The Data-new Alcova filesystems are only available from the login nodes, not on the compute nodes. Storage space on the MedicineBow global filesystems does not imply storage space on the ARCC Data-new Alcova or vice versa. For more information about new Alcova filesystem on Data -Alcova please see: Alcova <-Rename Data -on Alcova