Warum meldet ein NAS freien Speicherplatz, lehnt aber neue große Dateien ab?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Ein NAS kann freien Speicherplatz anzeigen und dennoch eine große Datei ablehnen, wenn das Kontingent, die Metadaten, das Dateilimit oder die beschreibbare Zuordnung des Ziels erschöpft ist.

Das Dashboard meldet möglicherweise den Speicherplatz des gesamten Pools, während die Freigabe zu einem kleineren Dataset, Thin-Volume, Benutzerkontingent, reservierten Dateisystem oder nahezu erschöpften Metadatenprofil gehört. Für einen großen Upload kann außerdem temporärer Speicherplatz, eine zweite Kopie oder eine einzelne Dateigröße erforderlich sein, die das Zieldateisystem nicht darstellen kann. Beginnen Sie mit dem exakt fehlschlagenden Pfad und dem Fehlercode, statt anzunehmen, dass die prominent angezeigte Zahl zum freien Speicherplatz den Vorgang beschreibt.

Ermitteln, welches Dateisystem und Limit die Freigabe tatsächlich verwendet

Ordnen Sie die SMB- oder Anwendungsfreigabe ihrem Hostpfad, Einhängepunkt, Dataset, Subvolume, Thin-Volume und zugrunde liegenden Pool zu. Erfassen Sie freie Blöcke, freie Inodes, die Benutzeridentität und die Größe der abgelehnten Datei.

GNU erklärt, dass df das mit einem Pfad verbundene eingehängte Dateisystem meldet und nicht jeden Pool, jedes Kontingent, jeden Snapshot oder jedes Anwendungs-Limit darüber oder darunter.

Wenn die Freigabe in eine Systempartition oder ein kleineres eingehängtes Dataset schreibt, ist der freie Speicherplatz des gesamten Pools unerheblich. Korrigieren Sie den Pfad oder Einhängepunkt, bevor Sie Daten auf der falschen Speicherebene löschen.

Benutzer-, Gruppen-, Dataset- und Freigabekontingente prüfen

Vergleichen Sie die Ansicht des Administrators zum freien Speicherplatz mit dem Kontingent, das für den tatsächlichen SMB-Benutzer, die Gruppe, das Dataset, das Projekt oder den freigegebenen Ordner gilt. Testen Sie mit demselben Konto, das den Fehler erhält.

Oracle dokumentiert, dass ZFS-Kontingente und -Reservierungen ein Dataset begrenzen können, obwohl im Pool weiterhin ungenutzter Speicherplatz vorhanden ist, oder verfügbare Kapazität für ein anderes Dataset reservieren.

Entfernen Sie Kontingente nicht global. Erhöhen Sie nur das nachweislich verantwortliche Limit oder verschieben Sie die Datei in ein Dataset, dessen Kapazitätsrichtlinie zur Arbeitslast passt.

Datenplatz mit Metadaten und Zuordnungsarbeitsbereich vergleichen

Prüfen Sie Daten, Metadaten, Systemzuordnung, Blockgruppen und dateisystemspezifische Reservierungszähler. Das Erstellen einer großen Datei kann zusätzlich zu den Nutzdatenbytes Metadatenaktualisierungen und Copy-on-Write-Arbeitsbereich erfordern.

Die Btrfs-Dokumentation weist darauf hin, dass Btrfs trotz sichtbar freiem Speicherplatz ENOSPC zurückgeben kann, wenn die Anforderungen an Zuordnung und Copy-on-Write nicht erfüllt werden können.

Wenn die Metadaten eingeschränkt sind, verwenden Sie unterstützte Diagnosen des Dateisystems und gezielte Wiederherstellungsmaßnahmen. Füllen Sie den verbleibenden Speicherplatz nicht mit einer weiteren großen Testdatei und starten Sie keinen ungefilterten Balance-Vorgang, ohne den verfügbaren Arbeitsbereich zu messen.

-15% OFF

Inodes und Dateisatzlimits prüfen

Erfassen Sie freie Inodes oder Dateisätze und zählen Sie kleine Dateien in Caches, E-Mail-Speichern, Miniaturansichten, entpackten Paketen und Anwendungsverzeichnissen. Eine große Byte-Kapazität garantiert nicht, dass ein weiterer Verzeichniseintrag oder Metadatensatz zugewiesen werden kann.

Red Hats Überblick über Dateisysteme erklärt, dass XFS Inodes dynamisch zuweist und dass Dateisystemimplementierungen unterschiedliche Inode- und Dateisatzlimits haben.

Wenn die Inodes erschöpft sind, entfernen oder archivieren Sie einen verifizierten Cache mit hoher Dateianzahl über die dafür zuständige Anwendung. Das Löschen einer einzelnen großen Datei behebt keinen Mangel an Dateisätzen.

Maximale Dateigröße und Format des Ziels überprüfen

Ermitteln Sie das Zieldateisystem und vergleichen Sie dessen maximale Dateigröße mit der Größe des versuchten Uploads. Beziehen Sie Wechseldatenträger, USB-Sicherungsziele und temporäre Anwendungsordner ein.

Die NTFS-Übersicht von Microsoft zeigt, dass die maximale Dateigröße vom Dateisystemdesign abhängt und von Zuordnungsparametern beeinflusst wird. Der insgesamt freie Speicherplatz hebt daher kein Limit des einzelnen Dateiformats auf.

Wenn der Fehler nahe einer konstanten Grenze wie 4 GB auftritt, prüfen Sie jedes zwischengeschaltete Dateisystem und den gesamten Uploadpfad. Eine Neuformatierung zerstört Daten. Migrieren Sie daher verifizierte Dateien an einen anderen Ort, bevor Sie das Zielformat ändern.

Anforderungen für temporäre Dateien, Sparse-Dateien und Vorabzuweisung messen

Prüfen Sie, ob der Uploader eine temporäre Datei schreibt, das gesamte Ziel vorab zuweist, die alte Version bis zum Umbenennen behält oder ein Archiv in zusätzliche Dateien entpackt. Erfassen Sie die maximale Zuordnung statt nur der endgültigen Dateigröße.

Der Systemaufruf fallocate reserviert Speicherplatz im Voraus, damit spätere Schreibvorgänge nicht wegen fehlender Kapazität fehlschlagen. Daher kann eine Anwendung eine große Datei ablehnen, bevor alle Daten übertragen wurden.

Wählen Sie ein temporäres Verzeichnis auf dem vorgesehenen Datenpool oder deaktivieren Sie die Vorabzuweisung nur, wenn die Anwendung dies sicher unterstützt. Lassen Sie während des Austauschs ausreichend Spielraum für das Original, die temporäre Kopie, Metadaten und Snapshots.

Den exakten Fehler mit einer kontrollierten Datei reproduzieren

Erstellen Sie Testdateien unterhalb und oberhalb der fehlschlagenden Größe mit demselben Benutzer, Protokoll, Pfad und derselben Anwendung. Erfassen Sie den Clientfehler und das Serverprotokoll, ohne die Produktivdatei wiederholt zu übertragen.

Der ZimaSpace-Leitfaden zum Auffinden unerwarteter NAS-Speichernutzung beschreibt die ergänzende Methode, sichtbare Ordner mit der tatsächlichen Dateisystemzuordnung abzugleichen.

Das Problem ist behoben, wenn das nachgewiesene Kontingent-, Metadaten-, Inode-, Format- oder Temporärspeicherlimit korrigiert wurde und eine Datei oberhalb der bisherigen Fehlergröße erfolgreich geschrieben, geschlossen, erneut geöffnet und verifiziert werden kann. Stoppen Sie Schreibvorgänge, wenn das Dateisystem schreibgeschützt wird oder Beschädigungen beziehungsweise Hardwarefehler meldet.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.