mabox schriebWie gesagt das ist ein Script das ich von jemanden habe wo pacman -Syu ausführt, davor noch einen Snapshot macht von / und noch ein paar Dinge. Am Ende auf jedenfall steht dann der balance Befehl von oben.
Es geht also um dieses Befehl:
btrfs balance start -dusage=5 /btrfs
mabox schrieb
Den würde ich jetzt gerne verstehen und falls er keinen Sinn macht dann halt entfernen
[root@arch ~]# btrfs fi df -g --si /btrfs
Data, RAID1: total=1243.39GB, used=1242.90GB
System, RAID1: total=0.03GB, used=0.00GB
Metadata, RAID1: total=3.22GB, used=1.95GB
GlobalReserve, single: total=0.54GB, used=0.00GB
Dann versuche ich es mal. Vorab:
Speicherplatz wird von der Hardware (und Kernel) auf den Platten in "Blöcken" belegt/angefordert. Jedes Byte von Daten belegt nun mindest einen Block. Speicherplatz kann nun "verschwendet" werden, wenn es viele Daten gibt, die kleiner sind als die genutzte Blockgröße. Im laufenden Betrieb und mit zunehmender Anzahl der schon belegten Blöcke steigt die Wahrscheinlichkeit, daß das passiert. Im allgemeinen wird das als Fragmentierung bezeichnet.
Btrfs organisiert diesen vorgegebenen Speicherplatz (die "Blöcke") nun intern ("low-level") in sogenannten "Chunks". Ein Chunk nutzt immer etliche der Blöcke, laut Doku ist ein Chunk normalerweise eine Größe von 1 GB.
Jeder durch Daten angeforderte neue Chunk erhöht nun immer den obigen "total="-Wert um die Chunk-Größe und vermindert den freien Platz entsprechend (was z.B. bei btrfs file usage <pfad> unter: Free(estimated) angezeigt wird oder mit Einschränkungen bei df -h).
Einschub: Kernel und Dateisysteme unter Unixen sind im allgemeinen sehr intelligent um "Fragmentierung" und interne "Verschwendung" zu vermeiden. Ein lange laufendes ext(3|4)-FS oder auch btrfs "leidet" nach meiner Erfahrung signifikant weniger unter Fragmentierungs-/Verschwendungs-Effekten als früher z.B. die Windows-Dateisysteme (fat,fat32,ntfs), die kurze Zeit nach einer Defragmentierung schon wieder eine erhebliche neue Fragmentierung aufwiesen (zumindest aus Systemsicht).
Wir schauen bei obiger df-Ausgabe nur nach den Werten für Data (System und Metadata lassen wir außen vor), da "Daten" nun mal den Hauptanteil des Speicherplatzes ausmachen.
Data, RAID1: total=1243.39GB, used=1242.90GB
Das heißt: aus dem gesamt verfügbaren Speicherplatz(Blöcke) verwendet das Volume(Pool) durch angefordete Chunks momentan 1243.39 GB (total=). "Optimal" wäre nun, wenn jeder belegte Chunk zu 100% auch durch reale Nutzdaten belegt wäre. Dieses "optimale Verhältniss" wird in der Praxis aber nie vorkommen. Hier zeigt nun der "used=" Wert durch reale Daten("Dateien") 1242.90 GB an.
Das "Verhältniss" von "Chunk-Belegung" zu "Daten-Belegung" ist nun:
1242.90 / 1243.39 = 0,99(gerundet)
Also momentan ein Verhältniss von total zu used von rund 99%, was sehr nahe an den 100% liegt <g>.
Was kann man aus diesem Zustand ableiten?
a) Jeder belegte Chunk ist im Durchschnitt zu 99% auch mit realen Nutzdaten belegt (Verschwendung von 1%)
Das alle belegten Chunks nun mit gerade diesem Durchschnitt belegt sind ist aber praktisch realitätsfern.
b) So ist eher zu erwarten, daß es Chunks gibt die mit weniger als 99% genutzt werden. Aber aus dem Verhältniss sind eher Belegungen in Richtung der 99% zu erwarten als in Richtung 1%. So wird sich hier real eher ergebenen, daß du einige wenige Chunks hast, die ungefähr nur zu 50%-70% bzw. 70%-85% belegt sind.
Weiterhin kann man durch:
1243.39GB(total) - 1242.90GB(used) = 0,49GB
rauslesen:
Durch eine wirklich optimale Nutzung würdest du momentan rund 500MB gewinnen können, der wieder für neue Daten/Snapshots in Btrfs zur Verfügung stände. Da daß aber gerade wohl mal ein "halbes Chunk" ist, wäre der "Gewinn" ... Null.
Und hier ist dann der Punkt wo Balancing als "Wartungstool" (nicht als Reparaturtool, wie wir es früher genutzt haben) ins Spiel kommen könnte:
# btrfs balance start -dusage=X <pfad>
ist ein Balance mit dem Filter auf die benutzten Daten( -d ist Daten/Data aus df oben, usage ist der verwendete Filter). Das ist also ein (wesentlich) eingeschränkter Balance-Lauf als ein full-balance.
Diesere Balance-(Filter)-Lauf würde eine Neuorganisierung der belegten Chunks (teils durch Neuschreiben von Chunks) erreichen mit dem Ziel, belegte Chunks möglichst komplett mit realen Daten zu füllen und somit die teilbelegten wieder frei verfügbar zu kriegen. Würde also versuchen Obiges total= von df oben möglichst nah zum used= zu kriegen, total= also zu vermindern.
Du aktuell würdest wohl (Differenz von ~500MB) nicht mal ein Chunk durch Neuorganisierung freikriegen, dein noch "junges" System zeigt ja, daß du kaum Chunks hast, die mit *wesentlich* weniger als 90% nur belegt sind. Da du den Pool/Volume ja wohl im wesentlichen durch "Kopieren-im-Rutsch-aus-Backup" gefüllt hast, zeigt das auch, daß Btrfs sich selbst um eine möglichst effizente Nutzung der Chunks kümmert.
Dein kompletter Befehl würde nun folgendes anstoßen:
Eine Neuorganisierung von durch Daten(Data) belegten Chunks, die nur zu 5% mit realen Nutzdaten belegt sind. Deine sind - haben wir festgestellt - "durchschnittlich" sogar zu 99% belegt. Wie wahrscheinlich ist es, da auch nur einen Chunk zu finden der "nur" mit bis zu 5% belegt ist? Nahezu Null IMHO...
Deshalb wunderte ich mich über dieses "-usage=5" auch, da ja jedesmal nur die belegten Chunks reorganisert würden die - umgekehrt - zu 95% nicht durch Nutzdaten auch belegt sind. Natürlich kann ein Chunk angefordert/belegt werden, da daß Dateisystem eine Datei(oder Daten) unterbringen muß von nur wenigen Bytes. Allerdings nutzt das System diesen Chunk dann sicher für andere Operationen, sodaß ein wirklich nur mit bis zu 5% belegter Chunk kaum vorkommen dürfte - und sich signifikant auf eine Verringerung von total= auswirken würde.
Ich nehme an - auch im weiteren "Wachsen" des Dateisystems - daß zum Zeitpunkt X du fast immer nur ein Ergebniss von:
reallocated 0 out of YYY chunks
bekommst, oder evtl. 1 bis 3 reorganisierte Chunks von allen. Also eine "Verschwendungsersparniss" von nur rund 0-3 GB. Also ein Wert, der den Zeit-/Ressourcen-Aufwand IMHO nicht rechtfertigt. Und der Zeitpunkt für diesen Befehl (im Zusammenhang nach einem Snapshot und pacman -Syu) macht IMHO aus diesem Blickwinkel noch weniger Sinn/Nutzen.
Wirklich zum Verständniss: -dusage=5 rührt keine Chunks an, die 6% bis 99% belegt sind. Dein Belegungsverhältniss haben wir oben schon analysiert, weit entfernt eine signifikante Anzahl von "5-Percentern" zu finden. Und das wohl auch in Zukunft.
Wann und wie macht ein Balance der Daten - mit dem Ziel, belegte Chunks in freie Chunks zu verwandeln - also Sinn?
Da wäre zum einen, der zu erwartende mögliche "Gewinn", der sich wie oben aus "total=" minus "used=" ungefähr abschätzen läßt. Also eine Ausgabe, die man von Zeit zu Zeit im Auge haben sollte.
Zum anderen spielen die Art der Nutzdaten und auch die Raid-Art eine Rolle. Wenn ich z.B. bei einem Webserver(Host) eine erkleckliche Anzahl von kleinen statischen HTML-Dateien oder Bildern erwarten kann, bei einem News-Server(wie der antike INN) eine erklecklicke Anzahl von kleinen News-Posting-Dateien - dann ist die Wahrscheinlichkeit, das total= von used= im Laufe stärker abweichen wird, also mehr nicht komplett genutzte Chunks auftreten, von Natur aus größer als z.B. bei Videodateien/Filmen. Ebenfalls ist AFAIK ein raid1 aus 2 Devices per se weniger von der Chunk-Verschwendung betroffen als z.B. ein Raid10 mit "drölfzig" Devices.
Ebenfalls wichtig ist eben, daß man bei "-dusage=X" für X einen Prozentwert wählt, der möglichst viele Chunks in die Reorganisierung einbezieht - bei vertretbarem Zeitaufwand (mehr angefaßte Chunks = längere Laufzeit) zum erwarteten Gewinn. Einen gewissen Anhalt kann man ja anhand der obigen Verhältniss-Berechnung ermitteln.
Die Btrfs-Doku nimmt in Beispielen meist 50% als Wert ("Glas halb voll / leer" Empfinden <g>) für einen periodischen Balance-Lauf (periodisch bedeutet aber hier eben nicht nach z.B. dieser pacman-Aktion, genausowenig wie ein Scrub-Lauf explizit danach sinnvoll wäre).
Ich würde dir raten für periodisches Balance:
Behalte die Werte von "btrfs file df" im Auge (das ist Aufgabe eines Administrators), und entscheide, wann im Laufe der Zeit du einen signifikanten Wert an freien Chunks durch eine Reorganisierung erhalten würdest, ergo: wann driften used= und total= weit auseinander. Und mit welchem (Prozent-)Wert sollte ich dann sinnvoll (Zeit/Ressourcen) arbeiten um an diesen "maximalen" erwarteten Zuwachsgewinn heranzukommen.
Kurz also: IMHO macht der Befehl in einem wie immer angelegten (snapshot/pacman)-Szenario keinen Sinn, da nutzlos.
Trotzdem kannst du es ja auch ausprobieren (und wie gesagt: viele Dinge werden erst im Lauf der Zeit, der Nutzung wirklich relevant), indem du:
time btrfs balance start -dusage=5 /btrfs
einfach mal startest. Dann siehst du zum reinen (durch time) die gebrauchte Zeit, und siehst wieviel aktuelle 5%-Chunks überhaupt reorganisiert würden und was es dir für df (total=) bringt.
Ebenfalls denkbar wären Erweiterungen in deinem Skript, die Ergebnisse dieses Balancings mitprotokollieren. Um nach einer Zeit abzuschätzen: werden ausreichend Chunks angefaßt und was ist der Zugewinn, hat sich der Autor dieses Skripts also doch was dabei gedacht oder andere Erfahrungen gemacht, die ich ad hoc nicht sehe. Ich weiß nicht, wie erfahren du im Shell-Skripten bist, ich würde an sowas denken:
Angenommen dein Skript macht auch das pacman -Syu quasi "unbeaufsichtigt", automatisch, was eigentlich IMHO nicht sinnvoll ist. Und es wird als root ausgeführt. Und du solltest noch da Paket time installiert haben (pacman -S time), welche die GNU-Version von time mitbringt.
...
(snapshot Teil)
...
(pacman -Syu Teil)
...
dann der zu untersuchende balance Lauf, den ich einbetten würde in:
echo "=========" >> /root/pacman-balance.log
date >> /root/pacman-balance.log
btrfs filesystem df -g --si /btrfs >> /root/pacman-balance.log
echo "Starte balance..., warten..."
/usr/bin/time -p -o /root/pacman-balance.log -a btrfs balance start -dusage=5 /btrfs >> /root/pacman-balance.log
btrfs filesystem df -g --si /btrfs >> /root/pacman-balance.log
...
(Rest vom Skript)
Diese Änderung führt ein wachsendes Logfile in /root/pacman-balance.log, bei dem vorm Balance ein df protokolliert wird, dann der Balance mit 5% ausgeführt wird, und danach nochmal ein df. Separiert werden die Läufe durch "======" gefolgt vom Datum.
So kannst du beobachten:
a) Wieviele chunks werden in so einer Situation in das Reorganisieren eingezogen? (relocate x out of y chunks)
b) Wieviel Zeit brauchte der Durchlauf?
c) Wieviel freie Chunks / Spiecherplatz hat die Aktion gewonnen? (beide df Ausgaben bei total= vergleichen)
Wenn du das mal eine Zeitlang, Wochen so laufen ließest, dann könnte der Sinn dieses Balancings langfristig belegbar abgeschätzt werden.
Zum Vergleich mal die df Ausgabe von meinem Btrfs-System, was schon einige Jahre läuft, nur als Anhalt:
# btrfs file df -g --si /
Data, RAID1: total=1162.86GB, used=1156.93GB
System, RAID1: total=0.04GB, used=0.00GB
Metadata, RAID1: total=3.22GB, used=1.58GB
GlobalReserve, single: total=0.54GB, used=0.00GB
Durch ein Balancing (was ich noch nie, außer Anfangs-Testphase gemacht habe) würde ich
1162.86 minus 1156.93 = 5,93
also rund 6GB zusätzlichen Platz durch Chunk-Reorganisierung "gewinnen".
Ich werde die Tage hier mal mit 5% und mit realistischeren 50-70% testen, wie sich ggf., used= und total= gegenüber darstellen nach dem Balancing.
Wie schon angeklungen, daß sind Aussagen, Hinweise aufgrund dem, wie ICH das Balancing meine verstanden zu haben. Lasse mich da gerne korrigieren.
Nochmal ein Nachtrag zu meiner anderen Aussage zu btrfs-subvolumes im letzten Post:
<...der einzige Nutzen von subvolumes bei btrfs ist IMHO die Snapshot-Funktionalität...>
Das war sehr kurzgegriffen von mir, die Btrfs-Doku liefert da bessere Argumente wann/warum Subvolumes "Sinn" machen:
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#When_To_Make_Subvolumes