Répertoire /project

From Alliance Doc
Revision as of 21:18, 19 September 2017 by Diane27 (talk | contribs)
Jump to navigation Jump to search
Other languages:

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

Question.png
[nom@serveur ~]$ mkdir $HOME/project/group_writable

suivi de

Question.png
[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 les espaces utilisés et disponibles pour scratch et projet sur Cedar et Graham, ou l'espace home sur Cedar, utilisez

Question.png
[nom@serveur ~]$ diskusage_report


Exemple

Dans notre exemple, Sue est chercheur principal et Bob est membre de son groupe. Au départ, les répertoires de Sue et Bob semblent structurés de manière identique.

  • /home/sue/scratch (lien symbolique)
  • /home/sue/projects (répertoire)
  • /home/sue/project (lien symbolique)
  • /home/bob/scratch (lien symbolique)
  • /home/bob/projects (répertoire)
  • /home/bob/project (lien symbolique)

Cependant, le lien symbolique scratch pointe sur des répertoires différents : /scratch/sue pour Sue et/scratch/bob pour Bob.

En supposant que Bob n'a qu'un seul rôle défini dans la base de données CCDB, project pour Bob serait identique à project pour Sue, et projects pour Bob serait identique à projects pour Sue. Aussi, si Sue et Bob n'ont aucun autre rôle et ne sont associés à aucun autre projet, chacun de leur répertoire projects ne comprendrait qu'un sous-répertoire def-sue pointant au même endroit que chacun de leur project.

Chacun de /home/sue/project, /home/bob/project, /home/sue/projects/def-sue et /home/bob/projects/def-sue pointeraient au même répertoire, soit /project/<numéro quelconque>. Ce répertoire est le meilleur endroit où partager les données de Sue et Bob; ils peuvent y créer des répertoires et ont un accès en lecture et en écriture. Ainsi, Sue peut créer un répertoire foo

$ cd ~/project
$ mkdir foo

et Bob peut copier des fichiers dans ~/project/foo, pour que les deux puissent y avoir accès.

En supposant maintenant que Sue a obtenu des ressources avec espace de stockage suite au concours d'allocation de ressources (comme c'est souvent le cas), il y aurait une autre entrée dans leurs répertoires projects respectifs, semblable à

~/projects/rrg-sue-ab

Ce répertoire servirait à stocker et partager les données pour un projet dans le cadre du concours.

Pour partager un fichier avec un utilisateur qui n’est pas parrainé par le chercheur principal, le plus simple est de configurer les permissions pour que cet utilisateur puisse lire le répertoire ou le fichier, habituellement par une liste de contrôle des accès (ACL); pour les détails, consultez la page Partage de fichiers. Notez que les permissions pour les systèmes de fichiers peuvent être modifiées pour tous les répertoires ou fichiers, et non seulement pour ceux de l’espace projet. Vous pouvez partager un répertoire de votre espace ‘’scratch’’ ou encore un sous-répertoire de votre espace projet. Par contre, l’utilisation d’ACLs n’est pas possible pour‘’home’’ sur Graham. Il est de bonne pratique de limiter le partage des fichiers aux espaces projet et ‘’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.

En résumé :

  • l'espace scratch est utilisé pour les fichiers privés et temporaires
  • l'espace home est habituellement utilisé pour un petit nombre de fichiers relativement privés (par exemple des scripts de tâches)
  • l'espace project du groupe est habituellement utilisé pour les données partagées puisque cet espace est persistant, sauvegardé et plutôt de grande taille (jusqu'à 10To et plus si alloué dans le cadre du concours d'allocation de ressources)