Use Cases für Hardlinks? [geschlossen]

40

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 .

Matthew Cline
quelle
4
Es gibt unten gute Antworten, aber bedenken Sie den (strittigen) historischen Kontext. Als Unix neu war, waren die Festplattenlaufwerke langsam und verfügten über eine begrenzte Kapazität und Pufferung. Ein fester Link war einfach ein weiterer direkter Eintrag im Dateisystem zu derselben Datei. Ob Sie auf ls zugegriffen haben oder wie Sie es gerne nannten , war unerheblich. Wenn Sie list zu einem Softlink gemacht hätten, müssten Sie ihn im Verzeichnis suchen, die spezielle Datei mit dem Namen list lesen, sicherstellen , dass die Datei ls vorhanden ist, ls im Verzeichnis suchen und die tatsächliche ls- Datei von der Festplatte lesen . Ein riesiger Leistungsunterschied!
RichF
16
Nun, der erste Hardlink zu einer Datei ist verdammt nützlich.
Hören Sie auf, Monica am
@OrangeDog: Ja, aber Sie benötigen nur ein Link-Count-Feld im Inode, wenn Sie mehrere Links unterstützen möchten. (Möglicherweise benötigen Sie ein Flag für die In-Memory-Version von Inodes, um den nicht verknüpften, aber noch offenen Fall zu behandeln. Fsck müsste nach einem Absturz ohne Journaling immer noch nach Inodes ohne Verknüpfungen suchen.)
Peter Cordes
1
POSIX-Verzeichnissemantik müsste anders gestaltet werden: ..Ist immer derselbe Inode wie .im übergeordneten Verzeichnis. Dinge wie findkönnen überprüfen, ob link-count = 2 ist, um Blattverzeichnisse zu erkennen, und statdie Einträge aus readdir vermeiden , um nach Unterverzeichnissen zu suchen. Dies ist jedoch nur eine geringfügige Funktion, die durch die Unterstützung von Hardlinks für Nicht-Verzeichnisdateien (regulär, Symlink, Gerät, Socket und Named-Pipe) aktiviert wird. (Ja, Symlinks haben ihre eigene Inode und können fest verlinkt werden.)
Peter Cordes
1
Ein Grund für die Verwendung von Hardlinks, die ich in meinem Review zu SO "globaler" Natur nicht gesehen habe. Stellen Sie sich ein Dateisystem vor, in dem Dateien im Allgemeinen klein sind (zum Beispiel kurze Memos). Um die Organisation zu gewährleisten, benötigen Sie möglicherweise Zeiger auf dieselbe Datei an verschiedenen Stellen. Bei Symlinks verbraucht jeder Zeiger eine Inode. Bei solchen Dateisystemen kann es bereits zu Problemen kommen, wenn die Inodes ausgehen. Die Verwendung von Hardlinks als Zeiger hilft bei diesem Problem. Inodes sind in der Anzahl begrenzt; Namen für sie sind nicht (zumindest nicht in gleicher Weise).
Mathguy

Antworten:

27

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.

Zigeuner-Zauberwirker
quelle
3
Zu Ihrer Information: BTRFS-Snapshots sind keine Hardlinks. Sie haben ein unterschiedliches Verhalten (z. B. durch Ändern einer Kopie wird die andere nicht geändert). Und statwird nur einen Link zeigen.
Derobert
@derobert Ich bin mir nicht sicher, wie Schnappschüsse funktionieren. Wenig Nachforschungen zeigen interessante Dinge. Bei unveränderten Dateien / Verzeichnissen wird statdieselbe Inode-Nummer, jedoch eine andere Geräte-ID angezeigt. Muss etwas damit zu tun haben, wie Sub-Volumes auf dem Haupt-Volume (selten gemountet) überlagert werden. Ich vermute, dass, wenn der Hauptdatenträger bereitgestellt wurde stat, eine Linkanzahl angezeigt würde, die der Anzahl der Snapshots entspricht, die diese Version der Datei enthielten. Wahrscheinlich kümmert sich COW darum, dass die Änderung keine Auswirkungen auf die anderen hat. Bloße Spekulationen, die auf milder Neugier beruhen, aber nicht neugierig genug sind, um tiefer zu graben.
Gypsy Spellweaver
Jeder Symlink hat einen eigenen Inode, so dass er einen Inode-Eintrag im Dateisystem belegt. Traditionelle Unix-Dateisysteme erfordern, dass Sie auswählen, wie viel Speicherplatz für Inodes zum Zeitpunkt der FS-Erstellung reserviert werden soll, anstatt ihn wie XFS nach Bedarf zuzuweisen. Daher ist es tatsächlich von Bedeutung, dass die Symlink-Version viel mehr Inodes verbraucht (auch abgesehen von den Auswirkungen auf den VFS-Cache-Speicherbedarf).
Peter Cordes
23

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.

Stephen Kitt
quelle
8
@MatthewCline Sie möchten dieses Verhalten bei der Verwaltung effizienter inkrementeller Sicherungen. Insbesondere wenn alte Backups gelöscht werden, müssten in einem Softlink-basierten Backup-System alle neueren Backup-Dateien / Links erneut auf eine gültige Basis überprüft und verlinkt werden, während Hardlinks diese Aufgabe auf Inode-Ebene "kostenlos" erledigen. Timeshift / Backintime verwenden beispielsweise häufig Hardlinks.
Orzechow
3
@orzechow Ich glaube nicht, dass Sie Hardlink-Verhalten in der Nähe Ihres Backup-Systems wollen. github.com/bit-team/backintime/wiki/… backintime geht dummerweise davon aus, dass alle Änderungen an Dateien von einem Zyklus zum Entfernen und Erstellen stammen und nicht direkt aktualisiert werden.
DepressedDaniel
10
@DepressedDaniel-Hardlinks sind in einem Backup-System in Ordnung. Sie möchten lediglich nicht, dass die Backups fest mit den Live-Dateien verknüpft sind. Ein Backup sollte aber auf keinen Fall direkt von einem Live-System aus erreichbar sein ...
Stephen Kitt
1
Dies ist keine Antwort - insbesondere ist es kein Anwendungsfall. Es ist nur eine Demonstration des Verhaltens von Hardlinks.
user394
1
@ Thomaspadron-mccarthy das ist ein missverständnis. BiT verwendet Hardlinks nur, um identische Dateien in verschiedenen Snapshots zu verknüpfen. Sie sind NICHT mit der Originaldatei verknüpft! (Ich bin der BiT Dev)
Germar
11

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'
$ 
Thrig
quelle
4
Aber wird das normalerweise nicht mit Softlinks erledigt?
Matthew Cline
1
@MatthewCline könnte es heute sein, aber Symlinks existierten laut Stevens in APUE nicht vor 4.2BSD (1983).
thrig
4
@thrig, die Frage fragt speziell nach Anwendungsfällen, die nicht durch Symlinks erreicht werden können oder die zumindest der Verwendung von Symlinks vorzuziehen sind. Ihre Antwort gilt sowohl für HLs als auch für SLs.
Marcelo
3
BusyBox nutzt dies maximal.
Max Ried
8

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.

Kamil Maciorowski
quelle
6

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.

Marcelo
quelle
1
Für Punkt 1 ist die Verwendung von uuids als 'kanonischem' Namen für Dateien und die symbolische Verknüpfung aller lesbaren Namen mit den uuids eine alternative Lösung.
R ..
Obwohl der Vorschlag von uuids akademisch korrekt klingt, klingt die Verwendung von uuids für Dateinamen nicht sehr praktisch, und auch hier besteht das Ziel darin, die Dinge zu vereinfachen, sie nicht schwieriger oder "weniger menschlich verständlich" zu machen. Außerdem wäre uudis für die "kanonische" Dateireferenz nur eine zusätzliche Indirektion zum eigentlichen Datei-Inode, sodass dieser Ansatz keinen Sinn macht, da er keinen Vorteil bietet, sondern nur Nachteile wie: Auswirkungen auf die Leistung, zusätzliche Speicherplatz zum Speichern weiterer Verzeichniseinträge mit einer Reihe von Dateien mit "seltsamen" Namen ...
Marcelo
5

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.

Paul Draper
quelle
4

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].)

phk
quelle
2
+1 weil dies konzeptionell ein sehr schöner Grund ist, aber leider ln -sfnicht atomar. Es löscht den alten Symlink und erstellt einen neuen. Um dies zu beheben, müssen Sie einen neuen Symlink mit einem temporären Namen und rename(2)( mv) dem Namen desjenigen erstellen, den Sie ersetzen möchten.
R ..
@ R .. Du hast recht! 😲 stat("uImage", {st_mode=S_IFREG|0777, st_size=0, ...}) unlink("uImage"),symlink("backup_image.bin", "uImage")
phk
1
Übrigens, siehe hier für meine Version install.sh, die das Problem löst: git.musl-libc.org/cgit/musl/tree/tools/install.sh
R ..
@R .. Beachten Sie, dass mvauch bei -fmöglicherweise ein Fehler auftritt , wenn das Ziel bereits als Symlink vorhanden ist, der Teil einer Symlink-Schleife ist. Demo:ln -sf foo bar; ln -sf bar foo; echo "Before:"; ls -l foo bar; >testfile; mv testfile foo || { echo "Using mv -f"; mv -f testfile foo; }; echo "After:"; ls -l foo bar
16.03.17
3

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.

Thomas Padron-McCarthy
quelle
3

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.

Dan Pritts
quelle