Btrfs-ENOSPC trotz scheinbar freiem Platz · Linux Fix Lab

Symptome und Geltungsbereich

Snapshot-Erstellung oder Metadatenänderungen scheitern mit No space left on device.
Der laut df freie Platz erklärt den Belegungsfehler nicht.

Betroffene Umgebung

Btrfs auf einem oder mehreren Geräten mit Copy-on-Write-Belegung und Snapshots.

Erkennbare Meldungen (synthetische Beispiele)

BTRFS: error (device sda2) in btrfs_commit_transaction: errno=-28 No space left

Metadaten und Belegung pro Gerät prüfen; generisches ENOSPC einer Anwendung weist diesen speziellen Mechanismus nicht nach.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Metadaten-Chunks, nicht belegter Platz pro Gerät oder ein Profilzwang können neue Belegung verhindern, obwohl Daten-Chunks intern noch Platz haben.
Snapshots halten referenzierte Extents; das Löschen einer sichtbaren Datei gibt deren Speicher nicht unbedingt sofort frei.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

/mountpoint durch dieses Btrfs-Mount ersetzen. Belegung und Nutzung pro Gerät lesen; Administratorrechte können nötig sein.

sudo btrfs filesystem usage -T /mountpoint

Ergebnis einordnen: Metadata used/total und Device unallocated einschließlich des aktiven Profils vergleichen. Die Gesamtschätzung freien Platzes garantiert keine erfolgreiche nächste Metadatenbelegung.

Prüfschritt 2

Subvolume- und Snapshot-Pfade des gewählten Mounts lesen; nichts wird gelöscht.

sudo btrfs subvolume list /mountpoint

Ergebnis einordnen: Viele Snapshots zeigen zu prüfende Historie, keine automatischen Löschkandidaten. Snapshots teilen Extents; ihre Größen lassen sich nicht einfach addieren.

Nächste Schritte nach Befund

Aufbewahrte Daten und Snapshots prüfen

Wenn ungenutzte Snapshots alte Daten halten, die Aufbewahrung im Backup- oder Snapshot-Werkzeug prüfen und nach Kontrolle unabhängiger Backups nur eindeutig entbehrliche Snapshots entfernen. Verzögerte Bereinigung abwarten und Belegung erneut prüfen.

Vorsicht: Ein Snapshot auf demselben Dateisystem ist kein unabhängiges Backup. Löschen verliert diesen Wiederherstellungspunkt und kann trotzdem Metadatenplatz benötigen.

Wiederherstellung / Rücknahme: Gelöschte Snapshots lassen sich nicht zuverlässig zurückholen; benötigte Historie aus dem unabhängigen Backup wiederherstellen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Eng gefilterten Balance-Lauf erwägen

Wenn die Belegung leere zugewiesene Chunks, aber zu wenig nicht belegten Platz zeigt, nach Prüfung des Upstream-Verfahrens einen Balance-Lauf mit usage=0-Filtern für Daten und Metadaten erwägen. Er gewinnt leere Blockgruppen zurück, ohne belegte Extents umzulagern.

Vorsicht: Auf einem fast vollen Dateisystem keinen ungefilterten Balance-Lauf starten; Umlagerung benötigt Arbeitsraum. Profiländerungen und zusätzliche Geräte benötigen einen eigenen Rettungsplan.

Wiederherstellung / Rücknahme: Balance ordnet Belegung um und besitzt keine Rückgängig-Funktion. Backups behalten; längere Umlagerung bei unerwarteten Fehlern abbrechen und Gerätezustand erneut prüfen.