Ich experimentiere mit LXC und verwende Btrfs als Sicherungsspeicher. Btrfs ermöglicht einfache Snapshots/Deduplizierung und ist ideal zum Hochfahren mehrerer „Pseudo-VMs“.
Das Problem, das ich habe, ist, dass einige der Apps, die ich teste, viele Daten auf die Festplatte schreiben. Ich versuche, die Nutzung des Btrfs-Volumes einzuschränken, also habe ich dem von LXC für einen bestimmten Container erstellten Subvolume ein Kontingent zugewiesen.
Die App verfügt über einen Ausfallsicherheitstest: Wenn sie feststellt, dass auf dem Dateisystem, in das sie schreibt, weniger als eine bestimmte Menge an freiem Speicherplatz (z. B. 512 MB) frei ist, beginnt sie, alte Protokolle zu löschen, um Platz für neue zu schaffen.
Das Problem besteht darin, dass das LXC-Root-Dateisystem selbst mit angewendetem Kontingent immer noch die volle Größe des Btrfs-Dateisystems des Hosts meldet.
Beispiel: Wenn mein Btrfs-Dateisystem 250 GB groß ist und ich einen LXC-Container mit den Optionen und erstelle -B btrfs, -shabe ich jetzt ein Untervolume im Btrfs-Dateisystem, das die Wurzel dieses neuen Containers darstellt. Dann möchte ich den vom Container belegten Speicherplatz begrenzen, also wende ich ein Qgroup-Limit von 32 GB auf den Container an. Wenn der dfBefehl jedoch im LXC-Container ausgeführt wird, zeigt er immer noch eine Gesamtdateisystemgröße von 250 GB und einen freien Speicherplatz an, der ungefähr auf dem tatsächlichen freien Speicherplatz des Host-Dateisystems basiert; d. h. die Kontingentgrenzen werden nicht angezeigt df.
Das bedeutet, dass meine Protokoll-App das gesamte Kontingent ausschöpfen kann und trotzdem noch glaubt, sie habe über 200 GB Schreibspeicherplatz, sodass sie ihre alten Daten nicht wiederverwendet. Irgendwann wird das Kontingent überschritten und aufgrund der Einschränkungen von COW-Dateisystemen muss ich das Kontingent deaktivieren und alte Protokolle manuell löschen. Wenn das Kontingent weiterhin in derselben Größe erzwungen wird, ist es nicht möglich, die Daten zu löschen, da für den Löschvorgang kein zusätzlicher Speicherplatz vorhanden ist.
Ich habe genug über Btrfs gelesen und verstehe genug davon, um zu verstehen, dass das Konzept des „freien Speicherplatzes“ in Btrfs verwirrend ist und eine Herausforderung darstellen kann, aber gibt es irgendeine Möglichkeit, innerhalb eines LXC auch nur eine ungefähre Angabe darüber zu erhalten, wie viel Kontingentspeicherplatz übrig bleibt? Vorzugsweise sollte dies über die Standard-APIs zum Abrufen des freien Festplattenspeichers (die von verwendet werden df) erfolgen, da dies bedeutet, dass es auch für andere Anwendungen gilt, die auf das Dateisystem zugreifen und den ungefähren freien Speicherplatz kennen müssen.
Wenn es mir möglich wäre, bis auf etwa 1 GB an den tatsächlich freien Speicherplatz (gemäß Kontingent) heranzukommen, würde mir das ausreichen, um die Parameter für das Ablaufen des Protokolls so anzupassen, dass das Dateisystem das Kontingent nicht überschreitet.
Antwort1
Hier ist das beste Tool, das ich für die Speicherplatzzuweisung von BTRFS-Subvolumes gefunden habe: Ermitteln Sie die Größe Ihrer BTRFS-Snapshots | PoisonPacket Blog
Alle Credits gehen an Kyle Agronick (Autor dieses Skripts)