Warum erschöpft eine hohe Dateianzahl die Inodes eines Heim-NAS, bevor der Festplattenspeicher voll ist?

Eine hohe Dateianzahl kann den Inode-Vorrat eines Heim-NAS erschöpfen, bevor die Datenblöcke aufgebraucht sind. Das Ergebnis wirkt widersprüchlich: Ein Kapazitätsbildschirm zeigt möglicherweise Gigabyte oder Terabyte frei an, doch ein Upload-, Backup-, Container- oder Indexierungsauftrag kann keine weitere Datei mehr erstellen.

Dies ist eine Dateisystembegrenzung, keine universelle Eigenschaft jedes NAS. Das klassische Problem ist am einfachsten bei ext4 und ähnlichen Dateisystemen mit definierter Inode-Anzahl zu erkennen, während XFS und Btrfs Metadaten anders zuweisen. Der Dateisystemtyp bestimmt daher, ob „freie Inodes“ die richtige Metrik sind oder nur ein Teil der Diagnose.

Ein Heim-NAS kann Objektslots erschöpfen, bevor Datenblöcke aufgebraucht sind

Die direkte Ursache ist, dass Dateidaten und Datei-Identität unterschiedliche Ressourcen verbrauchen. In ext4 speichert ein Inode Metadaten wie Zeitstempel, Eigentümer, Blockzuordnungen und erweiterte Attribute, während ein Verzeichniseintrag einen Namen mit einem Inode verknüpft. Die ext4-Inode-Dokumentation des Linux-Kernels beschreibt seine Inode-Tabelle als lineares Array, das über Blockgruppen verteilt ist.

Jede neue reguläre Datei benötigt normalerweise einen Inode, aber die Byte-Größe bestimmt nicht, wie viele Inodes sie benötigt. Ein 100-GB-Video kann einen Inode belegen, während eine Million winziger Cache-Dateien ungefähr eine Million Inodes benötigen können. Verzeichnisse und symbolische Links sind ebenfalls Dateisystemobjekte, während mehrere Hardlinks auf dieselbe Datei einen Inode teilen.

Freie Blöcke können daher verfügbar bleiben, nachdem der letzte freie Inode vergeben wurde. Zu diesem Zeitpunkt hat das NAS prinzipiell noch Platz für mehr Dateiinhalte, es fehlt jedoch die Metadaten-Identität, die zum Erstellen eines weiteren Objekts erforderlich ist. Kapazität und Objektanzahl sind unabhängig genug, dass beide beobachtet werden müssen.

Warum kleine Dateien die Inode-Nutzung schneller antreiben als die Kapazität

Kleine Dateien erzeugen eine hohe Objektdichte: Für relativ wenig Nutzlast werden viele Identitäten benötigt. Eine Null-Byte-Datei benötigt dennoch Metadaten, und ein Verzeichnisbaum fügt seine eigenen Verzeichnis-Inodes hinzu, noch bevor die darin enthaltenen Dateien gezählt werden. Deshalb kann eine Arbeitslast Dateislots viel schneller verbrauchen als die beworbenen Terabyte eines NAS.

Bei ext4 kann das Erstellungstool die Inode-Belegung aus einem Bytes-pro-Inode-Verhältnis berechnen oder eine explizite Inode-Anzahl akzeptieren. Die mke2fs-Inode-Zuweisungsoptionen besagen, dass ein größeres Bytes-pro-Inode-Verhältnis weniger Inodes erzeugt und dass das Verhältnis nach der Dateisystemerstellung nicht mehr geändert werden kann, obwohl das Vergrößern das konfigurierte Verhältnis durch Hinzufügen von Inodes mit neuem Speicherplatz beibehält.

Ein einfaches Planungsmodell ist ungefähre Inode-Belegung = Dateisystemgröße ÷ Bytes-pro-Inode-Verhältnis. Bei einem hypothetischen 16 KiB-Verhältnis entsprechen 1 TiB etwa 67 Millionen Inode-Slots, bevor Formatierungs-Overhead und Dateisystemgrenzen berücksichtigt werden. Dies ist eine Illustration, kein universeller NAS-Standard: Formatprofile und Dateisystemimplementierungen wählen unterschiedliche Richtlinien.

Was sich ändert, wenn der letzte freie Inode vergeben wird

Im klassischen Erschöpfungsfall beginnen Operationen, die einen neuen Inode benötigen, zu fehlschlagen. Neue Uploads, Verzeichnisse, temporäre Dateien, extrahierte Archivmitglieder und Anwendungsstatusdateien können alle abgelehnt werden, obwohl bestehende Dateien noch gelesen werden können. Eine bestehende Datei kann auch wachsen, wenn noch freie Datenblöcke vorhanden sind, da sie bereits einen Inode besitzt.

Anwendungen übersetzen den Zuweisungsfehler oft in eine generische Meldung „Kein Speicherplatz mehr auf dem Gerät“. Diese Meldung identifiziert eine fehlgeschlagene Ressourcenzuweisung, sagt dem Benutzer aber nicht, ob die fehlende Ressource Datenblöcke, Inodes, eine Quotenfreigabe oder dateisystemspezifischen Metadatenplatz war. Der sichtbare Fehler muss mit Dateisystemzählern kombiniert werden.

Welche Home-NAS-Arbeitslasten extreme Dateianzahlen erzeugen

Die risikoreiche Arbeitslast ist nicht einfach „große Daten“. Es ist jede Arbeitslast, die viele unabhängige Dateisystemobjekte erzeugt, besonders wenn Bereinigung oder Aufbewahrung diese Objekte über Monate ansammeln lässt.

Container-Schichten, Protokolle und Paketbäume

Container-Images, extrahierte Softwarepakete, Abhängigkeitsbäume, rotierende Protokolle und Anwendungscaches können eine große Anzahl kleiner Objekte unter einem NAS-gehosteten Dienst platzieren. Das Container-Image mag in Gigabyte bescheiden erscheinen, während seine entpackten Schichten und der beschreibbare Zustand weit mehr Objekt-Identitäten verbrauchen als eine Mediendatei gleicher Größe.

Foto-Miniaturansichten und Suchindizes

Ein Fotomanager kann für jedes Quellmedium Miniaturansichten, Vorschauen, Sidecars, Gesichtsausschnitte oder Indexfragmente erzeugen. Einige Anwendungen konsolidieren diese Datensätze in Datenbanken, während andere viele davon als gewöhnliche Dateien speichern. Der Inode-Effekt hängt daher vom Speicherdesign der Anwendung ab und nicht nur von der Größe der Fotobibliothek.

Synchronisationsverläufe, Backup-Bäume und Mail-Speicher

Versionskontrollsysteme, die Revisionen als Dateien materialisieren, Backup-Bäume mit vielen Quellobjekten und Mailstores mit einer Nachricht pro Datei können alle hohe Dateianzahlen erzeugen. Copy-on-Write-Snapshots und deduplizierte Repositories können Versionen unterschiedlich darstellen, daher sollte eine Snapshot-Anzahl nicht ohne Prüfung der Implementierung als direkte Inode-Anzahl behandelt werden.

Warum ein Kapazitäts-Dashboard Inode-Druck übersehen kann

Viele Dashboards betonen Bytes: Gesamtkapazität, genutzte Blöcke und freie Blöcke. Die Standard-Dateisystemstatistik-Schnittstelle führt Objektzähler getrennt als Gesamt-, freie und verfügbare Dateiserialnummern; unter Linux entsprechen diese Felder wie f_files und f_ffree in der statvfs-Dateisystemstatistik. Eine Benutzeroberfläche, die diese Felder weglässt, kann bei klassischer Inode-Erschöpfung gesund erscheinen.

Auf einem Linux-basierten NAS mit Shell-Zugang können Block- und Inode-Nutzung für denselben eingehängten Pfad verglichen werden:

df -h /pfad/auf/nas
df -i /pfad/auf/nas

Das GNU df-Handbuch definiert -i als Inode-Nutzung statt Blocknutzung und zeigt Gesamt-, genutzte, verfügbare und Prozentfelder an. Freie Blöcke bei null verfügbaren Inodes sprechen stark für klassische Inode-Erschöpfung; Spielraum in beiden Spalten weist auf eine andere Grenze hin.

Feste und dynamische Inode-Dateisysteme versagen unterschiedlich

„Das NAS hat keine Inodes mehr“ ist nur dann korrekt, wenn das Zuweisungsmodell des Dateisystems und die gemeldeten Zähler dies unterstützen. Dieselbe Fehlermeldung „kein Speicherplatz“ kann von einer anderen Metadaten-Grenze in einem anderen Dateisystem stammen.

Die XFS-Inode-Speicher-Richtlinie kann den prozentualen Anteil des Dateisystems begrenzen, der Inodes zugewiesen wird, während die offizielle Btrfs-Dateisystem-Berichterstattung Daten, System, Metadaten und GlobalReserve trennt. Diese Modelle können metadatenbezogene Grenzen erzeugen, sollten aber nicht so erklärt werden, als hätte jedes NAS dieselbe feste Inode-Tabelle.

Die generische Statistik-Schnittstelle warnt auch, dass nicht jedes zurückgegebene Feld auf jedem Dateisystem sinnvoll ist. Identifizieren Sie zuerst das eingehängte Dateisystem und interpretieren Sie dann df -i durch diese Implementierung, anstatt einen Befehl als universellen Beweis zu behandeln.

Was Inode-Reserven für die NAS-Kapazitätsplanung bedeuten

Eine Kapazitätsprognose für eine Arbeitslast mit vielen Objekten benötigt sowohl erwartete Bytes als auch erwartete Objektanzahl. Medienarchive sind normalerweise byte-dicht, während Abhängigkeitsbäume, Thumbnails, Mail-Speicher und materialisierte Backup-Bäume objekt-dicht sein können. Zwei Arbeitslasten mit derselben logischen Größe können daher sehr unterschiedliche Metadaten-Reserven benötigen.

Bei einem ext4-Volume ist das Verhältnis von Bytes zu Inodes eine Designentscheidung zur Formatierungszeit und kein normaler Live-Tuning-Regler. Eine Größenänderung kann Inodes im Einklang mit dem festgelegten Verhältnis hinzufügen, aber sie wählt nicht rückwirkend ein dichteres Profil. Eine Neuformatierung allein zur Änderung dieses Verhältnisses ist eine Migrationsentscheidung mit Backup- und Wiederherstellungskonsequenzen, kein beiläufiger Performance-Tweak.

Sobald der Inode-Druck ausgeschlossen wurde, bleiben gewöhnliche Fragen zur Blockkapazität separat; ein Plan für die NAS-Speicherkapazität zu Hause kann diese Entscheidung ergänzen, aber eine Anleitung zur freien Terabyte-Kapazität ersetzt keine Inode- oder Metadatenzählung.

Warum das Löschen einer großen Datei möglicherweise nicht genügend Inodes freigibt

Das Löschen eines großen Films kann viele Datenblöcke freigeben, aber normalerweise nur einen Inode. Das Entfernen eines Verzeichnisbaums mit Hunderttausenden entbehrlicher Cache-Objekte kann viele Inodes freigeben, selbst wenn die wiedergewonnene Byte-Kapazität vergleichsweise gering ist. Die Bereinigung muss auf die erschöpfte Ressource abgestimmt sein.

Ein nicht mehr verknüpftes Objekt wird nicht immer sofort zurückgewonnen. Das Linux unlink-Verhalten hält eine Datei am Leben, wenn ein Prozess noch den letzten Link geöffnet hat, und gibt sie erst frei, nachdem der letzte verweisende Dateideskriptor geschlossen wurde. Die Inode-Wiederherstellung kann daher hinter der Pfadnamenslöschung für aktive Protokolle oder Service-Dateien zurückbleiben.

FAQ

Verwendet jede Datei genau einen Inode?

Eine reguläre Datei hat normalerweise einen Inode, und Verzeichnisse sowie symbolische Links haben ebenfalls eigene Dateisystem-Identitäten. Mehrere Hardlink-Namen können auf denselben Inode zeigen, während dateisystemspezifische Funktionen zusätzliche Metadaten in separaten Objekten speichern können, sodass Pfadnamenanzahl und Inode-Anzahl verwandt, aber nicht immer identisch sind.

Kann ein SSD-Cache oder ein schnelleres Netzwerk eine Inode-Erschöpfung verhindern?

Nein. Schnellere Medien und Netzwerke können die Latenz verringern oder den Durchsatz erhöhen, aber sie schaffen keine zusätzlichen Inode-Slots in einer festen Inode-Population. Sie können eine Arbeitslast mit hoher Dateianzahl schneller abschließen lassen und so schneller das gleiche Metadatenlimit erreichen.

Funktioniert df -i funktioniert auf jedem Heim-NAS-Dateisystem?

Es meldet die Inode-ähnlichen Zähler, die über die gemountete Dateisystem-Schnittstelle bereitgestellt werden, aber diese Zähler haben möglicherweise nicht auf jedem Dateisystem dieselbe Bedeutung. Verwenden Sie es direkt für ext4-ähnliche Diagnosen und kombinieren Sie es mit dateisystemspezifischen Metadaten-Tools für XFS, Btrfs, ZFS oder ein Gerät, das das zugrunde liegende Volume abstrahiert.

Kann das Erweitern eines ext4-Dateisystems mehr Inodes hinzufügen?

Ja, das Vergrößern von ext4 kann Inodes hinzufügen, wenn neuer Speicherplatz eingebunden wird, während das bestehende Bytes-pro-Inode-Verhältnis beibehalten wird. Das unterscheidet sich vom Ändern des Verhältnisses auf dem bestehenden Dateisystem, was laut Dokumentation des Erstellungswerkzeugs nach der Formatierung nicht unterstützt wird.

Wird jeder „Kein Speicherplatz mehr auf dem Gerät“-Fehler durch Inodes verursacht?

Nein. Vollständige Datenblöcke, Quoten, reservierter Speicherplatz, Btrfs-Metadatenzuweisung, temporäre Speicherlimits und einige nicht-speicherbezogene Ressourcenlimits können ähnliche Meldungen erzeugen. Inode-Erschöpfung wird unterstützt, wenn der Fehler das Erstellen von Dateisystemobjekten betrifft und der entsprechende Inode-Zähler keine verfügbaren Einträge mehr hat.

Dateianzahl ist eine eigene Kapazitätsdimension

Ein Heim-NAS kann freien Speicherplatz behalten und dennoch keine neuen Objekte mehr annehmen, da Bytes und Dateisystem-Metadaten separate Kapazitätsdimensionen sind. Behandeln Sie eine hohe Dateianzahl als eine Eigenschaft der Arbeitslast, bestätigen Sie das tatsächliche Dateisystem und vergleichen Sie den Block-Headroom mit dem Inode- oder Metadaten-Headroom, bevor Sie schließen, dass die Festplatten voll sind.