Requestable Storage
The data stores other than the VAST SSD storage system are not as good at handling large numbers of small files. They can’t handle the high IOPS (IO Operations per Second) that such files entail. We highly recommend reworking computations to instead work with bundles of files when possible (higher performance), but sometimes this can’t be done. When this is the case, extra data stores on the VAST system can be made available to projects and users on special request (see Start Here for making a support request).
These extra storage systems have the following characteristics:
- Optimized for a moderately large number of files rather than capacity
- Optimized for high IOPS rather than bandwidth
- Has limited disk space per project/user
- Has a quota
The project Extra data stores for each kind of project are given in the table below (NHR and KISSKI Project on the same system).
| Kind of Project | Path | Project Map symlink | Media | Capacity | Filesystem |
|---|---|---|---|---|---|
| SCC | /mnt/vast-standard/projects/PROJECT | dir.vast-standard | SSD | 1.2 PiB (shared)(comp)(dedup) | VAST exported via NFS |
The user Extra data stores for each kind of user are given in the table below (SCC, NHR, and KISSKI HOME on the same system).
| Kind of User | Path | Media | Capacity | Filesystem |
|---|---|---|---|---|
| NHR | /mnt/vast-nhr/usr/USER | SSD | 1.2 PiB (shared)(comp)(dedup) | VAST exported via NFS |
| SCC | /mnt/vast-standard/usr/USER | SSD | 1.2 PiB (shared)(comp)(dedup) | VAST exported via NFS |
Legend for the tags in the Capcity column:
(shared): They share capacity with other data stores. For example, NHR Project and HOME data stores are on the same storage system.
(comp): Use live compression to increase effective capacity, though this comes at the expense of some CPU time to compress and decompress.
(dedup): Use deduplication to increase effective capacity.