11 votes

Que sont les "ID de projet" sous linux, comme mentionné dans le manuel de chattr ?

Je lisais le manuel pour chattr sur ma machine Linux ( kali4-amd64 ) quand j'ai vu ceci dans la liste des définitions des attributs de fichiers :

A directory with the 'P' attribute set will enforce a hierarchical
structure for project id's.  This means that files and directory created in
the directory will inherit the project id of the directory, rename
operations are constrained so when a file or directory is moved into
another directory, that the project id's much match.  In addition, a hard
link to file can only be created when the project id for the file and the
destination directory match.

Je ne sais pas personnellement ce qu'est un "identifiant de projet" en ce qui concerne Linux/UNIX, et beaucoup de recherches sur Google n'ont rien donné non plus, alors j'espère que quelqu'un ici pourra m'aider.

8voto

Kamil Maciorowski Points 57004

Ce que vous demandez fait partie du concept des quotas de projets. Les quotas de projet sont un moyen de gérer quota de disque . Un type de système de fichiers particulier peut ou non supporter les identifiants de projet. Concentrons-nous sur ext4 et commençons par man 8 tune2fs :

-O [^]feature[,...]
Définit ou efface les caractéristiques (options) indiquées dans le système de fichiers. [ ]

[ ]

project
Activez le suivi de l'ID du projet. Ceci est utilisé pour le suivi des quotas de projets.

quota Activer les inodes de quota du système de fichiers interne.

[ ]

-Q quota-options
Définit la fonction 'quota' sur le superbloc et travaille sur les fichiers de quota pour le type de quota donné. Les options de quota peuvent être une ou plusieurs des options suivantes :

[^]usrquota
Définit/supprime l'inode du quota utilisateur dans le superbloc.

[^]grpquota
Définit/supprime l'inode de quota de groupe dans le superbloc.

[^]prjquota Définit/efface l'inode de quota de projet dans le superbloc.

Vous pouvez activer ces options sur un système de fichiers existant :

tune2fs -O project,quota /your/device

(ou les fournir à mke2fs lors de la création d'un nouveau système de fichiers). Activez ensuite les quotas du projet (éventuellement avec des quotas d'utilisateurs et/ou de groupes si vous le souhaitez) :

tune2fs -Q prjquota /your/device

Montez-le :

mount /your/device /the/mountpoint

Vous pouvez désormais gérer les quotas avec des outils tels que setquota y quota (notez que les anciennes versions des outils peuvent être dépourvues de l'option -P qui gère les quotas des projets). Traditionnellement, vous limitez la quantité d'espace disque qu'un utilisateur ou un groupe peut utiliser. Avec les quotas de projet, vous pouvez le faire pour les "projets", indépendamment des utilisateurs et des groupes qui y participent.

Cela fonctionne comme suit. D'abord, placez-vous dans le point de montage et créez quelques répertoires :

cd /the/mountpoint
mkdir foo bar baz

Activez la hiérarchie de projet sur eux :

chattr +P foo bar baz

Affectez-les à deux projets différents :

chattr -p 123 foo       # 123 is an arbitrary number, project id
chattr -p 5 bar baz     # so is 5, the point is they are different

Créer des fichiers à l'intérieur :

echo "lorem ipsum" > foo/file1
echo "lorem ipsum" > bar/file2
echo "lorem ipsum" > baz/file3

Maintenant, invoquez :

lsattr -pR .

et vous verrez (entre autres) des lignes comme celle-ci :

  123 --------------e---P ./foo/file1
    5 --------------e---P ./bar/file2
    5 --------------e---P ./baz/file3

ce qui signifie file1 appartient au projet avec l'id 123 , file2 y file3 appartiennent au projet avec l'id 5 . Si vous définissez des quotas pour ces projets (c'est-à-dire que vous limitez la quantité d'espace disque que les projets peuvent utiliser), chaque fichier affectera la consommation du quota de son projet respectif.

Ce que vous avez cité a beaucoup de sens :

Les fichiers et les répertoires créés dans le répertoire hériteront de l'identifiant de projet du répertoire.

Dans notre exemple file1 a hérité de l'identifiant du projet de foo . Si vous créez d'autres fichiers/répertoires dans la section foo alors ils hériteront également de l'identifiant. Cela vous permet (ainsi qu'aux autres utilisateurs) de travailler sur le projet dans son répertoire désigné, tandis que les fichiers que vous créez sont automatiquement comptabilisés dans le quota correspondant.

un lien dur vers un fichier ne peut être créé que si l'identifiant du projet pour le fichier et l'identifiant de l'utilisateur sont identiques. répertoire de destination correspondent.

ln ./baz/file3 ./foo/ échouera (essayez-le) mais ln ./baz/file3 ./bar/ va réussir. Le système d'exploitation ne vous permet pas d'"incorporer" facilement un fichier qui appartient à un projet (et doit rester ainsi parce que le chemin d'accès à la source n'est pas dissocié) dans un répertoire de projet différent. Lier un fichier à l'intérieur de son projet est autorisé.

lorsqu'un fichier ou un répertoire est déplacé dans un autre répertoire, les identifiants du projet doivent correspondre.

Je pense que c'est plutôt trompeur. mv fera son travail même si les identifiants ne correspondent pas. Le fait est que si vous invoquez

mv baz/file3 foo/

l'outil va d'abord essayer de rename(2) le fichier vers le nouveau chemin, cela échouera (comme ln ci-dessus). Normalement ou dans le même projet, cela devrait réussir et le nom original devrait disparaître. Apparemment, ce comportement est la raison pour laquelle "les identifiants du projet doivent correspondre".

Mais mv ne sortira pas encore. C'est comme passer d'un système de fichiers à un autre : après que mv ne parvient pas à renommer, il se rabat sur le mode copie+suppression. En fait, il crée un copie (avec un nouveau numéro d'inode) dans le répertoire cible. Dans notre cas, la copie hérite de l'id de projet de foo (comme tout nouveau fichier dans ce répertoire), il affecte donc la consommation de quotas du projet 123 . Le chemin d'origine est alors délié. Cela peut affecter la consommation de quotas du projet 5 ou non : les liens durs ou les descripteurs de fichiers ouverts feront que l'inode et les données d'origine survivront.

Notez que c'est assez surprenant : un nouveau fichier est créé, les anciens hardlinks (s'il y en a) ne sont pas liés au nouveau fichier, les descripteurs de fichiers pointant vers l'ancien fichier n'ont rien à voir avec le nouveau ; comme si l'opération de déplacement était effectuée entre systèmes de fichiers.

Il y a un moyen de faire mv renommer au lieu de copier+supprimer. Si vous affectez manuellement le fichier original au projet cible

chattr -p 123 baz/file3

puis mv baz/file3 foo/ le déplacera vraiment sans le copier, sans casser les liens durs (s'il y en a). Mais notez que le numéro de projet appartient à l'inode (pas le chemin, pas le nom, pas l'entrée du répertoire) donc chattr -p affecte tous les hardlinks.

Ainsi, si vous devez déplacer un gros fichier (c'est-à-dire des données derrière un inode, et pas seulement un lien dur parmi d'autres) vers un autre projet, le fait de changer de projet puis de le déplacer vous évitera de copier inutilement.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X