☰

Was sind „Projekt-IDs“ in Linux, wie im Chattr-Handbuch erwähnt?

tag-icon • tag-icon linux unix file-attributes attributes
Was sind „Projekt-IDs“ in Linux, wie im Chattr-Handbuch erwähnt?

chattrIch habe gerade das Handbuch für auf meinem Linux-Rechner ( ) durchgelesen, kali4-amd64als ich in der Liste mit den Definitionen der Dateiattribute Folgendes sah:

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.

Ich weiß persönlich nicht, was eine „Projekt-ID“ im Zusammenhang mit Linux/UNIX ist, und auch viele Google-Suchen haben keine Ergebnisse gebracht, daher hoffe ich, dass mir hier jemand weiterhelfen kann.

Antwort1

Was Sie fragen, ist Teil des Konzepts der Projektquoten. Projektquoten sind eine Möglichkeit,Datenträgerkontingent. Ein bestimmter Dateisystemtyp kann Projekt-IDs unterstützen oder nicht. Konzentrieren wir uns auf ext4 und beginnen mit man 8 tune2fs:

-O [^]feature[,...]
Legen Sie die angegebenen Dateisystemfunktionen (Optionen) im Dateisystem fest oder löschen Sie sie. […]

[…]

project
Aktivieren Sie die Projekt-ID-Verfolgung. Dies wird für die Projektquotenverfolgung verwendet.

quota Aktivieren Sie interne Dateisystem-Quota-Inodes.

[…]

-Q quota-options
Legt die 'Quoten'-Funktion für den Superblock fest und arbeitet mit den Quota-Dateien für den angegebenen Quota-Typ. Quota-Optionen können eine oder mehrere der folgenden sein:

[^]usrquota
Legt fest/löscht den Benutzerkontingent-Inode im Superblock.

[^]grpquota
Legt fest/löscht den Gruppenquoten-Inode im Superblock.

[^]prjquota Legt fest/löscht den Projektquoten-Inode im Superblock.

Sie können diese Optionen auf einem vorhandenen Dateisystem aktivieren:

tune2fs -O project,quota /your/device

(oder geben Sie sie mke2fsbeim Erstellen eines neuen Dateisystems an). Aktivieren Sie dann das Projektkontingent (ggf. mit Benutzerkontingent und/oder Gruppenkontingent, wenn Sie möchten):

tune2fs -Q prjquota /your/device

Montieren Sie es:

mount /your/device /the/mountpoint

Jetzt können Sie Kontingente mit Tools wie setquotaund verwalten quota(beachten Sie, dass älteren Versionen der Tools möglicherweise die -POption zum Verwalten von Projektkontingenten fehlt). Traditionell würden Sie die Menge an Speicherplatz begrenzen, die ein Benutzer oder eine Gruppe verwenden kann. Mit Projektkontingenten können Sie dies für „Projekte“ tun, unabhängig von den teilnehmenden Benutzern und Gruppen.

Das funktioniert so. Begeben Sie sich zunächst in den Mountpoint und erstellen Sie einige Verzeichnisse:

cd /the/mountpoint
mkdir foo bar baz

Aktivieren Sie die Projekthierarchie darauf:

chattr +P foo bar baz

Weisen Sie sie zwei verschiedenen Projekten zu:

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

Erstellen Sie Dateien innerhalb von:

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

Rufen Sie nun auf:

lsattr -pR .

und Sie werden (unter anderem) Zeilen wie diese sehen:

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

Das bedeutet, file1dass es zum Projekt mit der ID gehört und zum Projekt mit der ID gehört . Wenn Sie für diese Projekte Kontingente definieren (d. h. den Speicherplatz begrenzen 123, den Projekte nutzen können), wirkt sich jede Datei auf den Kontingentverbrauch des jeweiligen Projekts aus.file2file35

Was Sie zitiert haben, macht durchaus Sinn:

Im Verzeichnis erstellte Dateien und Verzeichnisse erben die Projekt-ID des Verzeichnisses

In unserem Beispiel file1wurde die Projekt-ID von übernommen foo. Wenn Sie weitere Dateien/Verzeichnisse in erstellen, fooübernehmen diese ebenfalls die ID. Auf diese Weise können Sie (und andere Benutzer) im dafür vorgesehenen Verzeichnis an dem Projekt arbeiten, während die von Ihnen erstellten Dateien automatisch auf das jeweilige Kontingent angerechnet werden.

Ein Hardlink zu einer Datei kann nur erstellt werden, wenn die Projekt-ID der Datei und das Zielverzeichnis übereinstimmen.

ln ./baz/file3 ./foo/wird fehlschlagen (versuchen Sie es), aber ln ./baz/file3 ./bar/erfolgreich sein. Das Betriebssystem lässt Sie eine Datei, die zu einem Projekt gehört (und so bleiben muss, da der Quellpfad nicht entkoppelt ist), nicht einfach in ein anderes Projektverzeichnis „einbetten“. Das Verknüpfen einer Datei innerhalb ihres Projekts ist zulässig.

Wenn eine Datei oder ein Verzeichnis in ein anderes Verzeichnis verschoben wird, müssen die Projekt-IDs übereinstimmen

Ich denke, das ist ziemlich irreführend. mvwird seinen Job machen, auch wenn die IDs nicht übereinstimmen. Der Punkt ist, wenn Sie aufrufen

mv baz/file3 foo/

Das Tool versucht zunächst, rename(2)die Datei in den neuen Pfad zu verschieben. Dies schlägt fehl (wie lnoben). Normalerweise oder innerhalb desselben Projekts würde es erfolgreich sein und der ursprüngliche Name würde verschwinden. Anscheinend ist dieses Verhalten der Grund für „die Projekt-IDs müssen übereinstimmen“.

Aber mves wird noch nicht beendet. Es ist wie das Wechseln zwischen Dateisystemen: Wenn mvdie Umbenennung fehlschlägt, fällt es in den Kopier- und Löschmodus zurück. Tatsächlich wird einKopieren(mit einer neuen Inode-Nummer) im Zielverzeichnis. In unserem Fall erbt die Kopie die Projekt-ID von foo(wie jede neue Datei in diesem Verzeichnis), sodass sie den Kontingentverbrauch von project beeinflusst 123. Der ursprüngliche Pfad wird dann getrennt. Dies kann den Kontingentverbrauch von project beeinflussen 5, muss es aber nicht: Hardlinks oder offene Dateideskriptoren sorgen dafür, dass der ursprüngliche Inode und die ursprünglichen Daten erhalten bleiben.

Beachten Sie, dass es etwas überraschend ist: Es wird eine neue Datei erstellt, alte Hardlinks (sofern vorhanden) werden nicht mit der neuen Datei verknüpft und Dateideskriptoren, die auf die alte Datei verweisen, haben nichts mit der neuen zu tun, als ob der Verschiebungsvorgang zwischen Dateisystemen durchgeführt würde.

Es gibt eine Möglichkeit, umzubenennen, mvanstatt zu kopieren+löschen. Wenn Sie die Originaldatei manuell dem Zielprojekt zuweisen

chattr -p 123 baz/file3

dann mv baz/file3 foo/wird es wirklich verschoben, ohne es zu kopieren und ohne Hardlinks (falls vorhanden) zu unterbrechen. Beachten Sie jedoch, dass die Projektnummer zum Inode gehört (nicht zum Pfad, nicht zum Namen, nicht zum Verzeichniseintrag) und daher chattr -palle Hardlinks beeinflusst.

Wenn Sie also eine große Datei (also Daten hinter einem Inode, nicht nur einem von vielen Hardlinks) in ein anderes Projekt verschieben müssen, ersparen Sie sich durch das Ändern des Projekts und das anschließende Verschieben unnötiges Kopieren.

verwandte Informationen