There are different types of storage on the clusters. This is important to understand where to store which type of data.
Important: please note that Boabab and Yggdrasil have both the same architecture and logic regarding storage, however the data is not shared between the clusters.
We use a distributed parallel filesystem on our clusters called BeeGFS. Any data you put in $HOME
or in $HOME/scratch
folders are thereby accessible on the login node and on each compute node of the cluster. This means you don't need to waste time or resources to copy data on the nodes.
This is the storage space we offer on our clusters
Cluster | Path | Total storage size | Nb of servers | Nb of targets per servers | Backup | Quota size | Quota number files |
---|---|---|---|---|---|---|---|
Baobab | /home/ | 138 TB | 4 | 1 meta, 2 storage | Yes (tape) | 1 TB | - |
/srv/beegfs/scratch/ | 1.0 PB | 2 | 1 meta, 6 storage | No | - | 10 M | |
/srv/fast | 5 TB | 1 | 1 | No | 500G/User 1T/Group | - | |
Yggdrasil | /home/ | 495 TB | 2 | 1 meta, 2 storage | Yes (tape) | 1 TB | - |
/srv/beegfs/scratch/ | 1.2 PB | 2 | 1 meta, 6 storage | No | - | 10 M |
We realize you all have different needs in terms of storage. To guarantee storage space for all users, we have set a quota on home and scratch directory, see table above for details. Beyond this limit, you will not able to write to this filesystem. We count on all of you to only store research data on the clusters. We also count on your to periodically delete old or unneeded files and to clean up everything when you will leave UNIGE. Please keep on reading to understand when you should use each type of storage.
Your home
folder is located here: $HOME
.
It is available on the login node and on each compute nodes of the cluster.
In your home directory you can store any file needed for running your jobs : data, code, software, etc.
However, this is not a personal storage for data such as emails, private pictures, etc.
Please always use the the $HOME
variable in your script instead of using the full path. This is a good practice and will save you a lot of trouble.
A backup of your $HOME
folder is done daily.
For temporary storage, please read about the “Scratch directory” below.
Your $HOME
is only accessible by you (permission 0700
) ; you are not allowed to change the permissions and if you do, they are automatically reset every day. If you need to share files, please check Sharing files with other users.
As the storage is shared by everyone, this ensure a fair home usage and prevent users from filling it. It is important to lower the disk usage on home as this location is backuped and this takes a lot of time, especially if you have a lot of files.
What does it mean for you: if your home directory usage is higher than 1TB, you won’t be able to write to it anymore.
Error message:
Disk quota exceeded
To resume the situation, you should clean up some data in your home directory and or migrate some data to your scratch directory.
Your scratch
folder is located here: $HOME/scratch
.
It is available on the login node and on each compute nodes of the cluster. It has more space than $HOME
.
N.B. : $HOME/scratch
is a symbolic link to your user's folder in /srv/beegfs/scratch/
.
The scratch directory allows you to store any data that is not unique or that can be regenerated. Please use this to store any file that doesn't need a backup. You will typically use it as a storage when your application writes temporary data to disk. We thank you for your cooperation.
It is also acceptable to store for instance a large dataset that you use as an input data during your computation.
The content of this folder is persistent and accessible from any node, but there is no backup.
Your $HOME/scratch
is only accessible by you (permission 0700
) ; you are not allowed to change the permissions and if you do, they are automatically reset every day. If you need to share files, please check Sharing files with other users.
Also, the scratch directory is not a permanent storage solution, we strongly advise you to move/clean useless/unused data after your project.
As the storage is shared by everyone, this ensure a fair scratch usage and prevent users from filling it. We setup a quota based on the number of files you own, not the file size.
The maximum file count is currently set to 10M.
What does it mean for you: if the number of files in your scratch space is higher than 10M, you won’t be able to write to it anymore.
Error message:
Disk quota exceeded
To resume the situation, you should clean up some data in your scratch directory.
A new fast storage is available dedicated for jobs using multiples nodes and scratchlocal need to be shared between nodes.
Cluster | path | Total storage size | Nb of servers | Backup | Quota size | Quota number files |
---|---|---|---|---|---|---|
Baobab | /srv/fast | 5 TB | 1 | No | 500G by user & 1TB by group | - |
As the storage is shared by everyone, this ensure a fair scratch usage and prevent users from filling it. We setup a quota based on the total size.
You should clean up some data in your fast directory as soon as your jobs are finished.
On each compute node, a local scratch
folder is available and is located here : /scratch
.
It is available on all compute node of the cluster. Unlike $HOME/scratch
, the local scratch can only be used from the node itself and while your job is running.
It is usually fast and there is no overhead for using the network. It is also more efficient at dealing with a large amount of small files.
You usually use it for temporary files generated while your job is running and that do not need to be accessible at the end of the job.
Important : at the end of the computation, all files in that directory are automatically deleted. If you need to keep some files, you can add a command to your Slurm sbatch script to move them in the $HOME
or $HOME/scratch
directory at the end of the job.
node[001-005,007-021,023-056,058-059,061-066,093-101,103-111,140-156,180,186,203]
.
On each compute node, you can use the following private ephemeral spaces:
/dev/shm
: fastest storage, on RAM, be careful to request enough RAM)/var/tmp
: on local disk/tmp
: on local diskThose places are private and only accessible by your job.
If you need to access the data from more than one node, you can use a space reachable from all your jobs running on the same compute node. When you have no more jobs running on the node, the content of the storage is erased.
The path is the following: /share/users/${SLURM_JOB_USER:0:1}/${SLURM_JOB_USER}
See here for a usage example: https://hpc-community.unige.ch/t/local-share-directory-beetween-jobs-on-compute/2893
Sometimes you need to share files with some colleagues or your research group.
We provide two types of shared folders :
/home/share/
) - to share scripts and shared libraries for a common project/srv/beegfs/scratch/shares/
) - to share datasets for instance If you need one, please contact us by email :
$HOME/$SCRATCH
folder on the clusters. Even if you did, our automation scripts will break what you did.
umask 0002
(thus new files and directories will be created with 660 and 770 permissions, respectively), otherwise you will be asked for confirmation every time you want to modify a file or, even worse, you will not be able to create new files/folders.
This is a side-effect of the default permissions on Red Hat-based systems without User Private Groups (i.e. when the UID/GID differs, as it is the case on Baobab/Yggdrasil 1) ).
find . -type f -exec chown :share_xxx {} \;
Source : 2)
All the BeeGFS storage are shared. Although it is a pretty robust solution, the performance depends of the workload of all the users and can be impacted negatively. This is especially true on a cluster, where a single job may perform I/O from many different threads at the same time, even on multiple nodes.
BeeGFS uses two kind of storage servers.
ls
, find
, etc. and you don’t read the content. The metadata is stored on fast NVMe disks. See here for details about the infrastructure.The bottleneck is usually the metadata servers and you notice it while trying to browse files.
A performance killer is for example to read/write a lot of very small files or to traverse a directory with thousands of files. This is usually something the user himself has a control on and can avoid, for example by limiting the number of files per directory.
Also, think twice before launching those tools on a shared storage:
updatedb
find
ncdu
du
Best practices :
Since /home
and /srv/beegfs/scratch/
have quota enabled and enforced, we can quickly check the disk usage by fetching the quota information.
The script beegfs-get-quota-home-scratch.sh
gives you a quick summary :
(baobab)-[sagon@login2 ~]$ beegfs-get-quota-home-scratch.sh home dir: /home/sagon scratch dir: /srv/beegfs/scratch/users/s/sagon user/group || size || chunk files storage | name | id || used | hard || used | hard ----------------------------|------||------------|------------||---------|--------- home | sagon|240477|| 530.46 GiB| 1024.00 GiB|| 1158225|unlimited scratch | sagon|240477|| 2.74 TiB| unlimited|| 436030| 10000000
This includes all your data in $HOME
, $HOME/scratch
, but also any data in /home/share
and /srv/beegfs/scratch/shares
that belongs to you (if you are using a shared directory).
If you have space as well in /acanas
(The NASAC) you can check your quota and usage like this:
-bash-4.2$ quota --hide-device -s -f /acanas Disk quotas for user XXX (uid NNN): Filesystem space quota limit grace files quota limit grace 1975G 0K 3072G 15725k 0 0
There is no need to transfer files between compute nodes and the login as they share the same storage space ($HOME
and $HOME/scratch
).
However, if for some reason you need specifically to transfer something from the login
node to the local storage of a compute node, you can use sbcast
(but you probably shouldn't).
Your home
($HOME
) directory is backed up every day.
To avoid backing up temporary data, we ask you to be fair and store them in the $HOME/scratch/
directory.
There is no backup of the scratch
folder.
If you deleted something from the $HOME
directory, please contact us by email :
Please be aware that the backup retention is limited. The backup ruls are :
Thus we cannot guarantee to recover a version of a file more recent than 24h, or on the contrary a file you deleted a long time ago. Don't bargain based on the above mentioned rules, just contact us as soon as possible and we will see what is doable.
If you need to archive you results, you can use the following services:
Baobab isn't a long term archive service!
If you need to transfer files from “outside” the cluster, please refer to this documentation
If you need to mount an external share (NAS for example) on Baobab from command line, you can proceed as follow in your terminal.
Launch dbus:
[sagon@login2 ~] $ dbus-launch bash
mount the share, smb in this example:
[sagon@login2 ~] $ gio mount smb://server_name/share_name
This will prompt for the username, password and domain. If you are mounting an UNIGE network share such as the NASAC, it’s your ISIS credentials and the domain is ISIS.
The share will be mounted on /run/user/your_uid/gvfs/
You can access the files using standard POSIX tools such as cp
ls
etc but keep in mind that those
tools aren't meant to be used on non reliable media such as network share.
If you face an error when accessing a specific file, you can use gio copy
or rsync
as cp
replacement which
works better and handle network errors. The same for ls
etc.
When you don’t need to access the data anymore, you may unmount the share:
[sagon@login2 ~] $ gio mount -u smb://server_name/share_name
If you need to script this, you can put your credentials in a file in your home directory.
Content example with the credendtials stored in the file .credentials
.
username domain password
Mount example using credentials in a script:
[sagon@login2 ~] $ gio mount smb://server_name/share_name < .credentials
Do not store the credentials in the file .netrc
as the format conflict with other tools using it such as wget
.
The process that lets you access GVfs/Gio shares via CLI is called gvfsd-fuse and its first argument is the folder where GVfs/Gio shares are exposed to.
You can find such folder with the following command:
[sagon@login2 ~] $ ps ux | grep -e '[g]vfsd-fuse' sagon 196919 0.0 0.0 387104 3376 ? Sl 08:49 0:00 /usr/libexec/gvfsd-fuse /home/sagon/.gvfs -f -o big_writes
In this case, it means the mount will be done in /home/sagon/.gvfs
[sagon@login2 ~] $ pgrep -a -U $(id -u) dbus 196761 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session 224317 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
reference: 3)
All the compute nodes of our clusters have CernVM-FS client installed. CernVM-FS, the CernVM File System (also known as CVMFS), is a file distribution service that is particularly well suited to distribute software installations across a large number of systems world-wide in an efficient way.
A couple of repository are mounted on the compute and login node such as:
The content is mounted using autofs under the path /cvmfs
. It means that the root directory /cvmfs
may appears empty as long as you
didn't access explicitly one of the child directory. Doing so will mount the repository for a couple of
minutes and unmount it automatically.
Other flaghship repository available without further configuration:
[root@node002 ~]# ls /cvmfs [root@node002 ~]# ls -dl /cvmfs/grid.cern.ch drwxrwxr-x 56 cvmfs cvmfs 2 Feb 1 2010 /cvmfs/grid.cern.ch [root@node002 ~]# ls /cvmfs/ cvmfs-config.cern.ch grid.cern.ch
The EESSI did a nice tutorial about CVMFS readable on multixscale git repo.
Robinhood Policy Engine is a versatile tool to manage contents of large file systems. It daily scans the scratch beegfs filesystems. It makes it possible to schedule mass action on filesystem entries by defining attribute-based policies.
Each file matchinga policy will be recorded in a robinhood report and accessible by the owner.
LargeDir: Triggered if the directory contains more than 500 files
The more files a directory contains, the more impact it has on the performance of the filesystem and therefore on other users. So we stronghly encourage you to avoid The LargeDir .
OldFiles: Triggered if a file has not been accessed for more than 60 days
The colder the data, the less likely it is to be reused. This rule is widely verified on most storage systems. As scratch is not a permanent storage, cold data tends to take up space unnecessarily. Some files have not been opened/modified since 2013. What is the probability that it will be used again soon. (close to 0%)
If some files have been triggered by robinhood, a report will be displayed on the connection node:
(baobab)-[terminator@login2~]$ ############################################################################### Robinhood Report ############################################################################### Cluster storage usage: USER > /home | /srv/beegfs/scratch root > 107.48 GiB | 1.79 TiB Policies report: * LargeDir: 173 Triggered if the directory contains more than 500 files * OldFiles: 12307 Triggered if a file has not been accessed for more than 60 days Please check /srv/beegfs/scratch/log/robinhood/report/t/terminator.log for more details and clean them up if possible. ###############################################################################
This is not a decorative item and should be taken seriously, this report is intended to inform you of files that do not comply with the storage policy. This list of files should get your attention and prompt you to sort through your files, delete or migrate your data to permanent storage, or reduce the number of files in a directory to avoid a drop in performance.