KVM etabliert sich als Standardlösung zur Virtualisierung unter Linux. Der ADMIN-Schwerpunkt hilft beim Bau virtueller Linux-Maschinen, stellt das ... (mehr)

Chunks

Für eine regelmäßige Kontrolle der Checksumme auf allen Datenträgern im RAID kann ein »btrfs scrub start Path | Device « als Cron-Job eingesetzt werden. Im laufenden Betrieb werden bei einem Lese- oder Checksummen-Fehler die Daten automatisch von einer anderen Kopie gelesen und bei RAID 1 und RAID 10 die fehlerhafte Replika neu angelegt.

Btrfs reserviert Speicherplatz für Daten und Metadaten in fixen Einheiten, »Block Groups« genannt. Block Groups wiederum bestehen aus einem oder mehreren »Chunks« (je nach RAID-Level). Diese Chunks sind für Daten meistens 1 GByte und für Metadaten 256 MByte groß. Eine Ausnahme bilden die ersten Metadaten-Chunks, die von »mkfs.btrfs« mit 1 GByte angelegt werden, genug Platz vorausgesetzt. Bei Blockgeräten mit wenigen GByte Größe kommen auch Zwischengrößen zum Zug..

Jetzt erklärt sich auch, warum in dem zuvor angelegten Filesystem insgesamt 18 GByte an Festplattenplatz bereits zugewiesen sind: 16 x 1 GByte Benutzerdaten, 2 x 1 GByte Metadaten (weil doppelt abgelegt) und ein kleiner Teil für die speziellen System Chunks (dort befindet sich der B-Tree, der alle Chunks verwaltet). Bei Filesystemen unter 1 GByte verwendet Btrfs automatisch spezielle Mixed Chunks, die sowohl Benutzerdaten als auch Metadaten beinhalten, um den geringen Platz besser auszunutzen.

Die Metadaten belegen auf diesem Dateisystem zwar noch keine 80 MByte, aber es wurde auch noch nicht wirklich produktiv genutzt. Sind Chunks einmal einem Datentyp zugewiesen, werden diese (bis jetzt) auch nicht mehr automatisch freigegeben, wenn sie nicht mehr benötigt werden. Das kann dazu führen, dass ein Filesystem, das laut »df -h« noch über ausreichend Reserven verfügt, beim Anlegen neuer Daten früher als erwartet mit einer Fehlermeldung antwortet, dass kein Platz mehr frei ist – außer in den Metadaten-Bereichen. Das sind dann die berüchtigten »ENOSPC« -Fehler, über die viele Btrfs-Benutzer berichten, vor allem, weil sie in der Vergangenheit auch noch viel häufiger zu Unrecht ausgeworfen wurden. Bei Btrfs ist immer ein Blick auf die Ausgaben von »btrfs fi show« und »btrfs fi df mountpoint « notwendig, um den verbrauchten aber auch potenziell noch freien Platz in einem Dateisystem herauszufinden. Das gute alte »df -h« hat bei Btrfs nur begrenzte Aussagekraft, speziell wenn es um verlässliche Aussagen zu dem noch verfügbaren Platz geht.

Platz da!

Sollte es aus Platzgründen notwendig sein, Chunks wiederzuverwerten, bleibt nur der Ausweg, ein »btrfs balance« zu starten. Wie viel Platz dadurch zurückgewonnen werden kann, ist im Vorhinein leider nicht ermittelbar, und es gibt auch keine Möglichkeit eines Simulations-Laufes. Immerhin kann dieses Kommando im laufenden Betrieb auf ein Dateisystem angewendet werden (siehe Abbildung 4 ).

btrfs balance start /mnt &

So ein Balance-Lauf dauert je nach Füllgrad des Dateisystems und der Leistung des Systems entsprechend lang. Alle Daten werden einmal komplett gelesen und in neue Chunks geschrieben. Das bedeutet auch, dass für ein erfolgreiches Balance noch etwas Platz frei sein muss, zumindest so viel, um die erste ausgewählte Block Group kopieren zu können inklusive dem Platz, den die Metadaten, die während des CoW-Prozesses anfallen, benötigen.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023