Inodes, Hardlinks und Symlinks

Wie genau ein Linux System Dateinen und Ordner Speichert oder wie dann darauf referenziert wird, ist oft nicht allen klar.

Bevor wir beginnen einmal kurz die Grundlagen über Inodes. Inodes sind Datenstrukturen, dargestellt als eine ganze Zahl und einzigartig je Datei. Sie enthalten sämtliche Informationen wie Zugriffsrechte (Lesen, Schreiben, Ausführen), Eigentum, Gruppe, Dateiart, Dateigrösse, SELinux-Kontext und auch die Anzahl der «Links» welche auf den Inhalt der Datei zeigen. Der Inhalt der Datei selbst, sowie der Dateinamen werden seperat gespeichert und sind nicht im Inode enthalten.

Inodes anzeigen

Die Inode-Nummer einer Datei zeigt ls -i an. Vollständige Metadaten liefert stat:

[root@rlwebp01 ~]# ls -i swissmakers-apache-dos.conf
537286221 swissmakers-apache-dos.conf

[root@rlwebp01 ~]# stat swissmakers-apache-dos.conf
  File: swissmakers-apache-dos.conf
  Size: 520       	Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d	Inode: 537286221   Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2025-08-04 10:39:30.552986781 +0200
Modify: 2025-06-30 01:07:07.825337403 +0200
Change: 2025-06-30 01:07:07.825337403 +0200
 Birth: 2025-06-30 01:07:07.825337403 +0200

Der Dateiname der angezeigt wird, kommt vom Verzeichniseintrag, nicht nicht vom Inode. Ein Verzeichnis ist im Kern eine Tabelle, die Dateinamen auf Inode-Nummern abbildet. Diese Trennung ist die Voraussetzung dafür, dass Hardlinks und Symlinks überhaupt funktionieren können.

Wenn Inodes ausgehen

Bei der Formatierung eines Dateisystems wird eine fixe Anzahl Inodes reserviert. Bei ext4 ist die Standardeinstellung ein Inode pro 16 KB Speicher. Auf grösseren Systemen mit vielen kleinen Dateien (z.B. Mailserver, global Session-Caches, Elastcsearch Clustern ect..) reicht dieses Verhältnis nicht immer aus.

Das System meldet dann «No space left on device», obwohl df -h ausreichend freien Speicher anzeigt. Der zweite Blick gehört in solchen Fällen df -i:

[root@rlwebp01 ~]# df -i
Filesystem                                     Inodes  IUsed     IFree IUse% Mounted on
devtmpfs                                      2008078    474   2007604    1% /dev
tmpfs                                         2013666      3   2013663    1% /dev/shm
tmpfs                                          819200   1000    818200    1% /run
/dev/mapper/rl-root                         153659392 648597 153010795    1% /
/dev/sda1                                      524288    374    523914    1% /boot

Bei IUse% 100 lässt sich das Problem nur beheben, indem nicht mehr benötigte Dateien gelöscht oder das Dateisystem mit höherer Inode-Dichte neu erstellt wird (mkfs.ext4 -i …).

Hardlinks

Ein Hardlink ist ein zusätzlicher Verzeichniseintrag, der auf denselben Inode zeigt wie ein bereits bestehender Eintrag. Es gibt kein Original und keine Kopie, beide Namen sind gleichwertig. Der Inode kennt nur seinen Link-Counter.

Erstellt wird ein Hardlink mit ln:

[root@rlwebp01 blog]# echo "Swissmakers" > original.txt
[root@rlwebp01 blog]# ln original.txt hardlink.txt

[root@rlwebp01 blog]# ls -li
total 8
827116010 -rw-r--r--. 2 root root 12 May 14 15:13 hardlink.txt
827116010 -rw-r--r--. 2 root root 12 May 14 15:13 original.txt

Beide Einträge tragen dieselbe Inode-Nummer, der Link-Counter steht auf 2. Eine Änderung an original.txt ist sofort auch in hardlink.txt sichtbar, weil beide Namen auf exakt dieselben Datenblöcke verweisen.

Einschränkungen

Hardlinks haben zwei Hürden:

1. Dateisystem-gebunden: Inode-Nummern sind nur innerhalb eines Dateisystems eindeutig. Über Mountpoints hinweg funktionieren Hardlinks nicht.
2. Keine Verzeichnisse: Hardlinks auf Verzeichnisse sind per Default (für unprivilegierte User) gesperrt. Andernfalls liessen sich Schleifen erzeugen, die find, du oder Backup-Tools in Endlosschleifen schicken würden.

Wo werden Hardlinks Eingesetzt?

Die Stärke von Hardlinks liegt bei platzsparenden Snapshot-Backups. Tools wie rsnapshot oder rsync können pro Snapshot ein vollständiges Verzeichnis erstellen, kopieren aber z.B. nur veränderte Dateien neu. Unveränderte Dateien werden als zusätzlicher Hardlink im neuen Snapshot eingehängt:

[root@rlwebp01 blog]# rsync -a --link-dest=/tmp/backup/2026-05-08 /tmp/blog/ /tmp/backup/2026-05-09/

rsync wird überprüfen, ob Dateien, die im Quellverzeichnis (/tmp/blog/) vorhanden sind, auch im Link-Verzeichnis (/tmp/backup/2026-05-08) vorhanden sind. Wenn dies der Fall ist, werden Hardlinks zu diesen Dateien im Zielverzeichnis (/tmp/backup/2026-05-09/) erstellt, anstatt die Dateien physisch zu kopieren. Nach aussen wirkt jeder Snapshot wie ein Vollbackup. Der tatsächliche Speicherbedarf entspricht der Summe der Änderungen zwischen den Snapshots.

Symlinks

Ein Symlink (Symbolic Link, auch Soft Link genannt) ist eine eigenständige Datei mit eigenem Inode. Ihr Inhalt besteht aus einem Pfad. Bei jedem Zugriff folgt der Kernel diesem Pfad zur Zieldatei. Konzeptionell entspricht ein Symlink einer Verknüpfung unter Windows oder einem Alias auf macOS.

[root@rlwebp01 blog]# ln -s /etc/redhat-release symlink-to-sysrelaese

[root@rlwebp01 blog]# ls -li symlink-to-sysrelaese
827116011 lrwxrwxrwx. 1 root root 19 May 14 15:41 symlink-to-sysrelaese -> /etc/redhat-release

Das l in den Permissions kennzeichnet die Datei als Link, der Pfeil zeigt auf das Original. Den reinen Pfadinhalt gibt readlink zurück. Mit -f werden zusätzlich verschachtelte Symlinks und relative Pfade aufgelöst, sofern vorhanden:

[root@rlwebp01 blog]# readlink symlink-to-sysrelaese
/etc/redhat-release

[root@rlwebp01 blog]# readlink -f symlink-to-sysrelaese
/etc/rocky-release

Nice to Know

Symlinks dürfen praktisch alles, was Hardlinks nicht dürfen:

• Auf Ziele in anderen Dateisystemen zeigen
• Per Default auf Verzeichnisse zeigen
• Relative oder absolute Pfade enthalten

Der Preis dafür: Wird das Ziel verschoben oder gelöscht, zeigt der Symlink ins Leere. Solche «dangling symlinks» lassen sich mit find aufspüren (im optimalen Fall wird nicht angezeigt):

[root@rlwebp01 blog]# find /etc -xtype l

Wo werden Symlinks Eingesetzt?

In einem modernen Linux-System praktisch überall. Drei sehr typische Einsatzgebiete sind dabei:

• Versionsmanagement im Debian Universum, via update-alternatives: /usr/bin/python zeigt auf /etc/alternatives/python, dieser wiederum auf /usr/bin/python3.11. Ein Versionswechsel ist im Wesentlichen eine Symlink-Änderung.
• Systemd zum aktivieren oder deaktivieren von Services, welche beim Boot automatisch gestartet werden sollen wird nach absetzen von z.B. systemctl enable httpd ein Symlink erstellt: (Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.)
• Site-Konfigurationen: Bei Nginx und Apache kann ein vhost ganz einfach aktiviert werden, indem die Konfiguration aus sites-available nach sites-enabled verlinkt wird.

Hardlink oder Symlink?

Die Entscheidung lässt sich auf wenige Kriterien reduzieren:

Einfach gesagt: Hardlinks für deduplizierte Snapshots innerhalb eines Volumes, Symlinks für alles andere.

Was rm tatsächlich macht

rm löscht keine Dateien. Der Befehl ruft den Syscall unlink(2) auf, entfernt also einen Verzeichniseintrag und dekrementiert den Link-Counter im Inode. Der effektive Storage wird erst freigegeben, wenn zwei Bedingungen erfüllt sind:

1. Der Link-Counter steht auf 0
2. Kein Prozess hält die Datei mehr offen

Daraus ergeben sich zwei Verhaltensweisen, die im Server-Alltag regelmässig auftauchen.

Logrotation funktioniert ohne Service-Neustart. Solange ein Prozess die alte Logdatei offen hält, schreibt er weiter hinein, selbst wenn der Verzeichniseintrag bereits entfernt wurde. Erst beim Schliessen des File Descriptors oder nach einem SIGHUP zur Wiederöffnung wird der Speicher freigegeben.

Der Speicher bleibt nach rm belegt. Wenn ein Prozess eine grosse Datei offen hält und diese gelöscht wird, gibt das Dateisystem den Platz nicht frei. Diagnostizieren lässt sich das mit lsof:

[root@rlwebp01 blog]# lsof | grep deleted

In dieser Situation hilft kein weiteres rm. Erst der Restart oder ein kill -HUP des haltenden Prozesses gibt den benötigten Platz frei. Alternativ lässt sich der File Descriptor unter /proc/<pid>/fd/<n> mit truncate -s 0 direkt leeren, ohne den Prozess zu stoppen.

Fazit

Dateinamen in Linux sind nur Verzeichniseinträge, der Inode verwaltet die eigentliche Datei. Aus dieser Trennung erklären sich mehrere Eigenheiten, die im Informatiker-Alltag auftauchen: das Dateisystem ist trotz freiem Speicher voll, gelöschte Logfiles wachsen weiter.

Hardlinks und Symlinks machen diese Trennung weiter nutzbar. Hardlinks für deduplizierte Daten innerhalb eines Volumes, Symlinks als flexible Verknüpfung über mehrere Dateisysteme hinweg. Beide gehören seit den frühen Unix-Tagen zum Standardinventar der Linux-Administration und tauchen in fast jeder produktiven Umgebung auf.