Répertoire /project
Les espaces projet des systèmes de fichiers sur Cedar et Graham sont organisés selon des groupes à l'aide d'une interface utilisateur simple. L'accès à un espace projet se fait habituellement par des liens symboliques à partir de votre répertoire home. Les liens symboliques se présentent sous le format $HOME/projects/group_name. Le lien symbolique $HOME/project pointe sur le répertoire projet de votre groupe; pour les utilisateurs qui ont associés à plus d’un groupe, le lien pointe sur le groupe désigné comme étant leur groupe par défaut.
Dans l’espace réservé à un groupe, le chercheur principal est propriétaire du répertoire et les membres du groupe ont des permissions de lecture et écriture pour ce répertoire. Cependant, pour tout nouveau fichier enregistré dans le répertoire, les membres du groupe ont par défaut un droit de lecture seulement; pour que les membres puissent avoir un droit en écriture, la meilleure approche est de créer un répertoire particulier, ainsi
[nom@serveur ~]$ mkdir $HOME/project/group_writable
suivi de
[nom@serveur ~]$ setfacl -d -m g::rwx $HOME/project/group_writable
Sur le partage de données, la propriété de fichiers et les listes de contrôle d’accès (ACLs), voyez Partage de données.
Par défaut, un espace projet a un quota de 1To et cinq millions de fichiers; l’espace peut être augmenté jusqu’à 10To sur demande auprès du soutien technique. Si votre groupe dispose de quotas plus élevés par suite du concours d’allocation de ressources, vous avez été informé du quota qui vous est alloué pour l’année. Notez que l'espace de stockage alloué dépend de la grappe et ne peut en principe être utilisé sur une autre grappe.
Pour connaitre l’espace utilisé et l’espace disponible, utilisez la commande
[nom@serveur ~]$ diskusage_report
Exemple
Imagine that we have a PI (“Sue”) who has a sponsored user under her (“Bob”). Both Sue and Bob start with a directory structure that on the surface looks similar:
/home/sue/scratch(symbolic link)/home/sue/projects(directory)/home/sue/project(symbolic link)/home/bob/scratch(symbolic link)/home/bob/projects(directory)/home/bob/project(symbolic link)
The scratch link points to a different location for Sue (/scratch/sue) and Bob (/scratch/bob).
If Bob's only role was the one sponsored by Sue, then Bob's project would be the same as Sue's project, and Bob's projectswould be the same as Sue's projects. Further, if neither Sue nor Bob have any other roles or projects with Compute Canada, then each one's projects directory would just contain one subdirectory, def-sue, pointing to the same place as each one's project.
Each of /home/sue/project, /home/bob/project, /home/sue/projects/def-sue, and /home/bob/projects/def-sue would point to the same location, /project/<some random number>. This project directory is the best place for Sue and Bob to share data. They can both create directories in it, read it, and write to it. Sue for instance could do
$ cd ~/project $ mkdir foo
and Bob could then copy a file into the directory ~/project/foo, where it will be visible to both of them.
If Sue were to get a RAC award with storage (as is often the case these days), both she and Bob would find that there is a new entry in their respective projects directories, something like
~/projects/rrg-sue-ab
They should use this directory to store and share data related to the research carried out under the RAC award.
For sharing data with someone who doesn't have a role sponsored by Sue--- let's say Heather--- the simplest thing to do is to change the file permissions so that Heather can read a particular directory or file. See Sharing data for more details. The best idea is usually to use ACLs to let Heather read a directory. Note that these filesystem permissions can be changed for almost any directory or file, not just those in project--- you could share a directory in your scratch too, or in one of the subdirectories of projects, if you have several (a default one, one for a RAC, etc.). (Exception: ACLs are not available in Graham's /home. Best practice is to restrict file sharing to /project and /scratch.)
One thing to keep in mind when sharing a directory is that Heather will need to be able to descend the entire filesystem structure down to this directory and so she will need to have read and execute permission on each of the directories between /project and the directory containing the file(s) to be shared. We have implicitly assumed here that Heather has an account on the cluster but you can even share with researchers who don't have a Compute Canada account using a Globus shared endpoint.
If Heather is pursuing a serious and ongoing collaboration with Sue then it may naturally make sense for Sue to sponsor a role for Heather, thereby giving Heather access similar to Bob's, described earlier.
To summarize:
scratchspace is for (private) temporary fileshomespace is normally for small amounts of relatively private data (e.g. a job script),- Shared data for a research group should normally go in that group's
projectspace, as it is persistent, backed-up, and fairly large (up to 10 TB, or more with a RAC).