Use Cases für Hardlinks? [geschlossen]

In welchen Situationen möchte man eher einen Hardlink als einen Softlink verwenden? Ich persönlich bin noch nie auf eine Situation gestoßen, in der ich einen Hardlink über einen Softlink verwenden möchte, und der einzige Anwendungsfall, auf den ich beim Durchsuchen des Webs gestoßen bin, ist das Deduplizieren identischer Dateien .

Abgesehen von der in einem anderen Kommentar erwähnten Sicherungsverwendung, zu der meines Erachtens auch die Snapshots auf einem BTRFS-Volume gehören, ist ein Anwendungsfall für Hardlinks über Softlinks eine nach Tags sortierte Sammlung von Dateien. (Nicht unbedingt die beste Methode zum Erstellen einer Sammlung, eine datenbankgesteuerte Methode ist möglicherweise besser, aber für eine einfache Sammlung, die relativ stabil ist, ist es nicht schlecht.)

Eine Mediensammlung, in der alle Dateien in einem, flachen, Verzeichnis gespeichert und nach verschiedenen Kriterien in andere Verzeichnisse sortiert werden, z. B. Jahr, Thema, Künstler, Genre usw. Dies kann eine persönliche Filmsammlung oder das Kollektiv eines kommerziellen Studios sein funktioniert. Im Wesentlichen fertiggestellt, wird die Datei gespeichert, wahrscheinlich nicht modifiziert und sortiert, möglicherweise an mehreren Stellen durch Links.

Beachten Sie, dass die Begriffe "Original" und "Kopie" nicht für Hardlinks gelten: Jeder Link zur Datei ist ein Original, es gibt keine "Kopie" im normalen Sinne. Für die Beschreibung des Anwendungsfalls ahmen die Begriffe jedoch die Logik des Verhaltens nach.

Das "Original" wird im "Katalog" -Verzeichnis gespeichert, und die sortierten "Kopien" sind fest mit diesen Dateien verknüpft. Die Dateiattribute in den Sortierverzeichnissen können auf r / o gesetzt werden, um versehentliche Änderungen an den Dateinamen und der sortierten Struktur zu verhindern. Die Attribute im Katalogverzeichnis können r / w sein, sodass sie nach Bedarf geändert werden können. (Dies kann bei Musikdateien der Fall sein, bei denen einige Player versuchen, Dateien basierend auf in die Mediendatei eingebetteten Tags, Benutzereingaben oder Internetabruf umzubenennen und neu zu organisieren.) Da sich die Attribute der "Kopie" -Verzeichnisse von denen unterscheiden können Im "Original" -Verzeichnis könnte die sortierte Struktur der Gruppe oder der Welt mit eingeschränktem Zugriff zur Verfügung gestellt werden, während der "Hauptkatalog" nur dem Hauptbenutzer zugänglich ist. mit vollem Zugriff. Die Dateien selbst haben jedoch immer die gleichen Attribute für alle Links zu diesem Inode. (ACL könnte untersucht werden, um dies zu verbessern, aber nicht mein Wissensgebiet.)

Wenn das Original umbenannt oder verschoben wird (das einzelne "Katalog" -Verzeichnis wird beispielsweise zu groß, um es zu verwalten), bleiben die Hardlinks gültig, Softlinks werden unterbrochen. Wenn die "Kopien" verschoben werden und die Softlinks relativ sind, werden die Softlinks wieder unterbrochen und die Hardlinks nicht.

Hinweis: Es scheint Inkonsistenzen zu geben, wie verschiedene Tools die Datenträgernutzung melden, wenn es sich um Softlinks handelt. Bei Hardlinks scheint dies jedoch konsistent zu sein. Wenn also 100 Dateien in einem Katalog in eine Sammlung von "Tags" einsortiert sind, können problemlos 500 verknüpfte "Kopien" vorhanden sein. (Für eine Fotosammlung sagen Sie Datum, Fotograf und durchschnittlich 3 "Betreff" -Tags.) Dolphin gibt beispielsweise an, dass 100 Dateien für Hardlinks und 600 Dateien für Softlinks verwendet werden. Interessanterweise wird derselbe Speicherplatz in beiden Richtungen angegeben, sodass eine große Sammlung kleiner Dateien für Softlinks und eine kleine Sammlung großer Dateien für Hardlinks angezeigt wird.

Eine Einschränkung für diese Art von Anwendungsfall ist, dass in Dateisystemen, die COW verwenden, das Ändern des "Originals" die Hardlinks, aber nicht die Softlinks beschädigen kann. Wenn die Hauptkopie jedoch bearbeitet, gespeichert und sortiert werden soll, tritt COW nicht in das Szenario ein.

Harte Links sind nützlich für Fälle, in denen Sie nicht die Existenz beider Dateien verknüpfen möchten. Bedenken Sie:

touch a
ln -s a b
rm a

Jetzt bist es nutzlos. (Und diese Schritte können ziemlich weit voneinander entfernt sein und von verschiedenen Personen ausgeführt werden.)

Während mit einem festen Link,

touch a
ln a b
rm a

b ist immer noch vorhanden und korrekt.

Ein einzelnes Programm kann sein Verhalten abhängig von dem Namen ändern, unter dem es gestartet wird:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

Was über in der Quelle entschieden wird über sowas

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

Die genauen Details variieren jedoch je nach Betriebssystem und Sprache.

Dies ermöglicht, dass (größtenteils) identischer Code nicht zu zwei (größtenteils) identischen Binärdateien kompiliert werden muss. Denken Sie daran, dass Unix-Daten bis zu Tagen, an denen Speicherplatz sehr teuer war, verwendet wurden, obwohl laut Stevens in APUE Kapitel 4 Symlinks in BSD4.2 (1983) implementiert wurden, um verschiedene Einschränkungen von Hardlinks zu ersetzen. Ein Testprogramm zur Überprüfung, ob der Symlink-Name als Programmname verwendet wird, sieht möglicherweise folgendermaßen aus:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

Und getestet über:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

Wenn meine P2P-Software den Download einer bestimmten Datei abgeschlossen hat, wird die Datei in einem bestimmten Verzeichnis abgelegt. Heruntergeladene Dateien müssen kaum bearbeitet werden. In der Regel erstelle ich einen Hardlink in einem anderen Verzeichnis, in dem sich die Datei befinden muss.

Vorteile:

• Ich immer noch die Datei in P2P - Netzwerk teilen , wie ich soll , auch wenn ich rmoder mvdie „Kopie“.
• Die Datei befindet sich auch dort, wo ich sie benötige. Die meisten dieser Standorte werden nicht gemeinsam genutzt.
• Ich kann rmdas "Original" aufhören, die Datei zu teilen; Dieser Vorgang wirkt sich nicht auf die "Kopie" an der gewünschten Stelle aus.
• Mein Speicherplatz wird nur einmal verwendet.

Das Wichtigste: Wenn ich rmvorher wüsste, welche Datei ich zuerst haben würde , würde ich vielleicht mit symlink gehen. Aber ich weiß es nie.

Dateisysteme sind eine einfache und dennoch effiziente Methode zum Organisieren und Klassifizieren von Dateien (dies ist der Hauptgrund für ihre Existenz). Hardlinks ermöglichen dabei ein höheres Maß an Flexibilität.

Wie bereits erwähnt, gibt es beim Umgang mit Hardlinks kein Konzept von Originalen und Kopien. Alle Verzeichniseinträge (Hardlinks) verweisen lediglich auf die Existenz der Datei (zeigen auf ihren Inode) ohne Vorrang, daher gibt es auch keine defekten Hardlinks. .

Daher gibt es hier einige Anwendungsfälle, bei denen Hardlinks auftreten , Softlinks jedoch nicht :

1. Stellen Sie sich vor, Sie haben eine Sammlung von Filmen, Musik oder anderen Medien und möchten unterschiedliche Klassifizierungskriterien anwenden, z. B. Songs, die von einem Künstler in einer Branche klassifiziert wurden (jeder Künstler hat ein eigenes Unterverzeichnis). nach Genre in einem anderen Zweig (jeweils in einem anderen Unterverzeichnis) usw. Sie möchten jedoch weder die Dateien duplizieren noch entscheiden, wo das "Original" abgelegt werden soll, damit Sie die Freiheit haben, eine Neuklassifizierung vorzunehmen, ohne dies zu tun. verwalten "und verknüpfen Sie Dateien beim Verschieben erneut, um fehlerhafte Verknüpfungen zu vermeiden.

2. Ein weiterer Grund besteht darin, die Verschwendung von Speicherplatz zu vermeiden, die erforderlich wäre, um mehrere Kopien derselben Datei zu haben, und es dem chrootSyscall dennoch zu ermöglichen , von einer Untergruppe von Dateien im Stammverzeichnis des "Master" -Dateisystems zu profitieren (symbolische Links könnten niemals auf Dateien von außerhalb verweisen) die chrootSandbox, auch wenn sie relative Pfade haben).

3. Ein weiterer sehr wichtiger, aber selten genannter Grund für die Existenz von Hardlinks sind die ..Unterverzeichnisse. Die ..Verzeichnisse sind tatsächlich (in den meisten Unix-fs-Implementierungen) Hardlinks zum übergeordneten Verzeichnis, ohne Hardlinks muss dies auf eine völlig andere Weise implementiert werden, während das Vorhandensein von Hardlinks die Implementierung sehr einfach macht.

Sehr verbreitetes, reales Beispiel, das Hardlinks benötigt:

git clone --reference <repository>

Dies klont von einem lokalen Git-Repo mit nahezu null Kopiervorgängen. Anstatt die Objektdateien (unveränderliche Dateien, die Git für seine "Datenbank" verwendet) zu kopieren, werden sie einfach per Hardlink verknüpft.

Jedes Repo kann ein Objekt entfernen, aber der Inode bleibt für den Rest der Repos gültig. Und wenn ein Objekt aus allen Repos entfernt wird, wird es von der Festplatte gelöscht. Harte Verbindungen sorgen für eine schöne, robuste und schnelle Lösung. Sehr häufig bei CI-Servern.

Es ist eine nicht-hard-Link - Version: git clone --shared <repository>. Dies ist jedoch launisch und hat viel mehr Vorbehalte, da alle an demselben Verzeichnis arbeiten.

Ich hatte kürzlich einen Anwendungsfall für ein etwas sicheres Aktualisierungsverfahren für U-Boot-basierte Systeme, bei dem uImageein Softlink auf das zu startende Image verweist. Die Idee war, dass ein Stromausfall keine Probleme aufwerfen sollte, egal zu welchem ​​Zeitpunkt in der Prozess passiert es (vorausgesetzt, das Dateisystem spielt mit):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Ohne Hardlinks wäre das nicht so einfach.

/bearbeiten:

Dank der Kommentare weiß ich jetzt, dass es besser wäre:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

(Das rmist hier, um einem fremden Zustand besser entkommen zu können, zB wenn uImageetwas Unerwartetes mvscheitern würde [aber nicht unbedingt die vorherige ln -sfLösung].)

Eine Verwendung, die ich für harte Links hatte, ist das Herunterladen oder Dekomprimieren einer defekten Datei. Das Programm, das das Herunterladen oder Dekomprimieren durchführt (wie z. B. Entpacken oder Entpacken), entfernt die unvollständige Datei häufig automatisch, wenn ein Fehler auftritt. In der Regel gibt es keine Option, die Datei beizubehalten. Wenn ich die Datei behalten möchte, kann ich einen festen Link dazu erstellen.

BackupPC ist ein Backup-System, das Hardlinks auf den Servern verwendet, um die Deduplizierung auf Dateiebene zu ermöglichen.

Dateien werden zuerst in einem "Pool" -Verzeichnisbaum basierend auf ihrem MD5-Hash gespeichert. Jede Sicherung, die diese Datei verwendet, stellt eine feste Verbindung zur Pool-Datei her. Wenn Backups ablaufen oder gelöscht werden, werden ihre festen Links aus dem Dateisystem entfernt.

Harte Links sind hier weichen Links überlegen, da sie eine automatische Referenzzählung ermöglichen. Ein Cron-Job löscht regelmäßig alle Dateien im Poolverzeichnis, die nicht mehr als eine Verknüpfung haben.

Diese Methode hat einige Nachteile (hauptsächlich ist es schwierig, dateisystembasierte Tools zum Replizieren des Sicherungsspeichers zu verwenden), hat sich jedoch in der Praxis als recht robust erwiesen.

Ein weiterer Anwendungsfall: Der Tomcat Java-Webanwendungsserver behandelt Dateinamen als Metadaten. Eine Java "war" -Datei muss anhand ihres Pfads auf dem Webserver benannt werden.

Beispiel: foo.war Ist der Java-Code, der die URL bedient/foo

Leider werden Symlinks aufgelöst, bevor diese Entscheidung getroffen wird.

Angenommen, Sie möchten einen Anwendungsbuild bereitstellen und ihm einen beschreibenden Dateinamen geben (z. B. mit einer Versionsnummer oder einem Datum). Sie können keinen Symlink zu der Datei mit dem "echten" Namen erstellen - Sie müssen einen Hardlink erstellen.

foo.warSymlink zu foo-20170129.warfunktioniert nicht

foo.warfest mit foo-20170129.warWerken verbunden.

Ich mag dieses Kater-Verhalten nicht, aber Hardlinks geben mir einen Weg, es zu umgehen.