Project layout/fr: Difference between revisions

Latest revision as of 21:27, 27 April 2023

Other languages:

English
français

Page enfant de: Stockage et gestion de fichiers

Voir aussi Message Disk quota exceeded

Les espaces /project des systèmes de fichiers sur Béluga, Cedar, Graham et Narval sont organisés selon des groupes. L'accès à /project 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.

Dans l’espace réservé à un groupe, la chercheuse ou 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

[name@server ~]$ mkdir $HOME/projects/def-profname/group_writable

suivi de

[name@server ~]$ setfacl -d -m g::rwx $HOME/projects/def-profname/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 /project a un quota de 1To et 500 000 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 pour l’allocation de ressources, vous connaissez le 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, utilisez

[name@server ~]$ diskusage_report

Pour faire en sorte que les fichiers copiés ou déplacés dans /project appartiennent au même groupe et soient comptabilisés dans le quota prévu, il peut être utile d'attribuer le bit setgid au répertoire approprié. De cette manière, tous les nouveaux fichiers et sous-répertoires ajoutés sous le répertoire en question héritent du même groupe que leur parent; de plus, les sous-répertoires héritent aussi de setgid. Cependant, l'appartenance au groupe n'est pas modifiée pour les fichiers et sous-répertoires déjà existants, ce qui se fait par la commande chgrp; aussi, tout fichier déplacé dans le répertoire conserve son appartenance de groupe. Pour attribuer setgid à un répertoire, utilisez la commande

[name@server ~]$ chmod g+s <directory name>

Pour attribuer setgid aux sous-répertoires existants, utilisez la commande

[name@server ~]$ find <directory name> -type d -print0 | xargs -0 chmod g+s

Pour plus d'information sur setgid, consultez cette page.

La commande newgrp modifie votre groupe par défaut pendant une session interactive; par exemple

[name@server ~]$ newgrp rrg-profname-ab

Copiez ensuite les données vers le répertoire /project approprié. Cependant, le groupe par défaut est modifié uniquement pour cette session; vous devrez utiliser newgrp à nouveau pour changer le groupe par défaut à votre prochaine connexion.

Si vous recevez des messages d'erreur Disk quota exceeded (voir Message Disk quota exceeded), ceci peut très bien être dû au fait que des fichiers sont associés au mauvais groupe, notamment votre groupe personnel, c'est-à-dire le groupe qui porte le même nom que votre nom d'utilisateur et qui a un quota de seulement 2Mo. Pour trouver et résoudre un problème de propriété de groupe pour ces fichiers, vous pouvez utiliser la commande

 find <directory name> -group $USER -print0 | xargs -0 chgrp -h <group>

où <group> est quelque chose comme def-profname, donc un groupe qui possède un quota raisonnable d'un téraoctet ou plus.

Exemple

Dans notre exemple, Sue est chercheuse principale 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/bob/scratch (lien symbolique)
/home/bob/projects (répertoire)

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'ait qu'un seul rôle défini dans CCDB, le répertoire project de Bob aurait le même contenu que les répertoires project de 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, soit def-sue.

Chacun de /home/sue/project, /home/bob/project, /home/sue/projects/def-sue et /home/bob/projects/def-sue pointerait 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 ~/projects/def-sue
$ mkdir foo

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

En supposant maintenant que Sue ait obtenu des ressources avec de l'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 une utilisatrice qui n’est pas parrainée par la chercheuse principale, par exemple Heather, le plus simple est de configurer les permissions pour que celle-ci puisse lire le répertoire ou le fichier, habituellement par une liste de contrôle des accès (ACL); pour les détails, voyez la page Partage de données. 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 votre espace /project. Vous pouvez partager un répertoire de votre espace /scratch ou encore un seul sous-répertoire particulier de votre espace /project. Il est de bonne pratique de limiter le partage des fichiers aux espaces /project et /scratch.

N’oubliez pas que Heather devra probablement avoir accès à plus d’un niveau de la structure du système de fichiers; il faut lui accorder les permissions de lecture et d’écriture pour chacun des répertoires entre ~/projects/def-sue et le répertoire où sont situés les fichiers à partager. Nous avons supposé que Heather détient un compte sur la grappe en question, mais il est aussi possible de partager des données avec des chercheuses et chercheurs qui n’ont pas de compte avec l'Alliance, en créant un point de chute commun dans Globus.

Bien sûr, si Heather devient une collaboratrice régulière de Sue, cette dernière pourrait la parrainer et lui accorder les mêmes accès que ceux accordés à Bob.

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)

@@ Line 1: / Line 1: @@
 <languages />
-Les espaces projet des systèmes de fichiers sur [https://docs.computecanada.ca/wiki/Cedar/fr Cedar] et [https://docs.computecanada.ca/wiki/Graham/fr Graham] sont organisés selon des '''groupes''' à l'aide d'une interface utilisateur simple.
+:''Page enfant de: [[Storage_and_file_management/fr|Stockage et gestion de fichiers]]''
-L'accès à un espace projet se fait habituellement par des liens symboliques à partir de votre répertoire ''home''.
+: Voir aussi [[Frequently_Asked_Questions/fr#Message_Disk_quota_exceeded |Message ''Disk quota exceeded'']]
-Les liens symboliques  se présentent sous le format <tt>$HOME/projects/group_name</tt>. Le lien symbolique <tt>$HOME/project</tt> 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
+Les espaces /project des systèmes de fichiers sur [[Béluga]], [[Cedar/fr|Cedar]], [[Graham/fr|Graham]] et [[Narval]]  sont organisés selon des <i>groupes</i>.
-{{Commande|mkdir $HOME/project/group_writable}}
+L'accès à /project se fait habituellement par des liens symboliques à partir de votre répertoire /home.
+Les liens symboliques se présentent sous le format <code>$HOME/projects/group_name</code>.
+Dans l’espace réservé à un groupe, la chercheuse ou 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
+{{Command|mkdir $HOME/projects/def-profname/group_writable}}
 suivi de
-{{Commande|setfacl -d -m g::rwx $HOME/project/group_writable}}
+{{Command|setfacl -d -m g::rwx $HOME/projects/def-profname/group_writable}}
 Sur le partage de données, la propriété de fichiers et les listes de contrôle d’accès (ACLs), voyez [https://docs.computecanada.ca/wiki/Sharing_data/fr 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 [mailto:support@computecanada.ca soutien technique]. Si votre groupe dispose de quotas plus élevés par suite du [https://www.computecanada.ca/page-daccueil-du-portail-de-recherche/acces-aux-ressources/concours-dallocation-des-ressources/?lang=fr 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.
+Par défaut, un espace /project a un quota de 1To et 500&nbsp;000 fichiers; l’espace peut être augmenté jusqu’à 10To sur demande auprès du [[Technical support/fr| soutien technique]]. Si votre groupe dispose de quotas plus élevés par suite du [https://alliancecan.ca/fr/services/calcul-informatique-de-pointe/acces-aux-ressources/concours-pour-lallocation-de-ressources concours pour l’allocation de ressources], vous connaissez le 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.
-<div class="mw-translate-fuzzy">
+Pour connaitre les espaces utilisés et disponibles, utilisez
-Avec la commande
+{{Command|diskusage_report}}
-{{Commande|diskusage_report}}
-vous pouvez connaitre les espaces utilisés et disponibles pour ''scratch'' et projet sur Cedar et Graham ou l'espace ''home'' sur Cedar.
+Pour faire en sorte que les fichiers copiés ou déplacés dans /project appartiennent au même groupe et soient comptabilisés dans le quota prévu, il peut être utile d'attribuer le <i>bit</i> <code>setgid</code> au répertoire approprié. De cette manière, tous les nouveaux fichiers et sous-répertoires ajoutés sous le répertoire en question héritent du même groupe que leur parent; de plus, les sous-répertoires héritent aussi de <code>setgid</code>. Cependant, l'appartenance au groupe n'est pas modifiée pour les fichiers et sous-répertoires déjà existants, ce qui se fait par la commande <code>chgrp</code>; aussi, tout fichier déplacé dans le répertoire conserve son appartenance de groupe. Pour attribuer <code>setgid</code> à un répertoire, utilisez la commande
-</div>
+{{Command|chmod g+s <directory name>}}
+Pour attribuer <code>setgid</code> aux sous-répertoires existants, utilisez la commande
+{{Command|find <directory name> -type d -print0 {{!}} xargs -0 chmod g+s}}
+Pour plus d'information sur <code>setgid</code>, consultez [https://fr.wikipedia.org/wiki/Setuid#setgid_pour_les_repertoires cette page].
+La commande  <code>newgrp</code> modifie votre groupe par défaut pendant une session interactive; par exemple
+{{Command|newgrp rrg-profname-ab}}
+Copiez ensuite les données vers le répertoire /project approprié. Cependant, le groupe par défaut est modifié uniquement pour cette session; vous devrez utiliser  <code>newgrp</code> à nouveau pour changer le groupe par défaut à votre prochaine connexion.
+Si vous recevez des messages d'erreur <i>Disk quota exceeded</i> (voir [[Frequently_Asked_Questions/fr#Message_Disk_quota_exceeded |Message <i>Disk quota exceeded</i>]]), ceci peut très bien être dû au fait que des fichiers sont associés au mauvais groupe, notamment votre groupe personnel, c'est-à-dire le groupe qui porte le même nom que votre nom d'utilisateur et qui a un quota de seulement 2Mo. Pour trouver et résoudre un problème de propriété de groupe pour ces fichiers, vous pouvez utiliser la commande
+  find <directory name> -group $USER -print0 | xargs -0 chgrp -h <group>
+où <code><group></code> est quelque chose comme <code>def-profname</code>, donc un groupe qui possède un quota raisonnable d'un téraoctet ou plus.
 === 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:
+Dans notre exemple, Sue est chercheuse principale et Bob est membre de son groupe. Au départ, les répertoires de Sue et Bob semblent structurés de manière identique.
 <div style="column-count:2;-moz-column-count:2;-webkit-column-count:2">
 * <code>/home/sue/scratch</code> (lien symbolique)
 * <code>/home/sue/projects</code> (répertoire)
-* <code>/home/sue/project</code> (lien symbolique)
 * <code>/home/bob/scratch</code> (lien symbolique)
 * <code>/home/bob/projects</code> (répertoire)
-* <code>/home/bob/project</code> (lien symbolique)
 </div>
-The scratch link points to a different location for Sue (<code>/scratch/sue</code>) and Bob (<code>/scratch/bob</code>).
+Cependant, le lien symbolique ''scratch'' pointe sur des répertoires différents : <code>/scratch/sue</code> pour Sue et <code>/scratch/bob</code> pour Bob.
-If Bob's only role was the one sponsored by Sue, then Bob's <code>project</code> would be the same as Sue's <code>project</code>, and Bob's <code>projects</code>would be the same as Sue's <code>projects</code>.  Further, if neither Sue nor Bob have any other roles or projects with Compute Canada, then each one's <code>projects</code> directory would just contain one subdirectory, <code>def-sue</code>, pointing to the same place as each one's <code>project</code>.
+En supposant que Bob n'ait qu'un seul rôle défini dans CCDB, le répertoire <code>project</code> de Bob aurait le même contenu que les répertoires <code>project</code> de Sue, et <code>projects</code> pour Bob serait identique à <code>projects</code> 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 <code>projects</code> ne comprendrait qu'un sous-répertoire, soit <code>def-sue</code>.
-Each of <code>/home/sue/project</code>, <code>/home/bob/project</code>, <code>/home/sue/projects/def-sue</code>, and <code>/home/bob/projects/def-sue</code> would point to the same location, <code>/project/<some random number></code>. 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
+Chacun de <code>/home/sue/project</code>, <code>/home/bob/project</code>, <code>/home/sue/projects/def-sue</code> et <code>/home/bob/projects/def-sue</code> pointerait au même répertoire, soit <code>/project/<numéro quelconque></code>. 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 <code>foo</code>
-  $ cd ~/project
+  $ cd ~/projects/def-sue
   $ mkdir foo
-and Bob could then copy a file into the directory <code>~/project/foo</code>, where it will be visible to both of them.
+et Bob peut copier des fichiers dans <code>~/projects/def-sue/foo</code>, pour que les deux puissent y avoir accès.
-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 <code>projects</code> directories, something like
+En supposant maintenant que Sue ait obtenu des ressources avec de l'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 <code>projects</code> respectifs, semblable à
   ~/projects/rrg-sue-ab
-They should use this directory to store and share data related to the research carried out under the RAC award.
+Ce répertoire servirait à stocker et partager les données pour un projet dans le cadre du concours.
-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 [https://docs.computecanada.ca/wiki/Sharing_data 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 <code>project</code>--- you could share a directory in your <code>scratch</code> too, or in one of the subdirectories of <code>projects</code>, if you have several (a default one, one for a RAC, ''etc.''). (Exception: ACLs are not available in [[Graham|Graham's]] <code>/home</code>. Best practice is to restrict file sharing to <code>/project</code> and <code>/scratch</code>.)
+Pour partager un fichier avec une utilisatrice qui n’est pas parrainée par la chercheuse principale, par exemple Heather, le plus simple est de configurer les permissions pour que celle-ci puisse lire le répertoire ou le fichier, habituellement par une liste de contrôle des accès (ACL); pour les détails, voyez la page [[Sharing data/fr|Partage de données]]. 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 votre espace /project. Vous pouvez partager un répertoire de votre espace /scratch ou encore un seul sous-répertoire particulier de votre espace /project.
+Il est de bonne pratique de limiter le partage des fichiers aux espaces /project 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 <code>/project</code> 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 [https://docs.computecanada.ca/wiki/Globus#Globus_Sharing Globus shared endpoint].
+N’oubliez pas que Heather devra probablement avoir accès à plus d’un niveau de la structure du système de fichiers; il faut lui accorder les permissions de lecture et d’écriture pour chacun des répertoires entre <code>~/projects/def-sue</code> et le répertoire où sont situés les fichiers à partager. Nous avons supposé que Heather détient un compte sur la grappe en question, mais il est aussi possible de partager des données avec des chercheuses et chercheurs qui n’ont pas de compte avec l'Alliance, en créant un [[Globus/fr#Partage_de_fichiers_avec_Globus | point de chute commun]] dans Globus.
-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.
+Bien sûr, si Heather devient une collaboratrice régulière de Sue, cette dernière pourrait la parrainer et lui accorder les mêmes accès que ceux accordés à Bob.
 En résumé :

Project layout/fr: Difference between revisions

Latest revision as of 21:27, 27 April 2023

Exemple

Navigation menu

Search