Work in Progress !!!
Nachdem gefühlt jeder 2. Windows-umsteiger nachfragt, wie man manjaro defragmentieren kann, und ich selbst immer antworte dass das unnötig sei, will ich das jetzt an meiner schon länger bestehenden Installation kontrollieren.
Gibt es Fragmentierung in btrfs?
Erste Fußangel: Das sind wirklich 2 Themen die man nicht mischen sollte:
Fragmentierung des “free space” !
Das findet ständig statt. Wenn btrfs aber nicht zu voll ist (80%), wird das automatisch im normalen Betrieb ausreichend bereinigt.
Es muss aber unbedingt darauf geachtet werden, dass möglichst nie alle chunks “allocated” sind. Das ist dann das berühmt berüchtigte “out of space”.
Dabei nutzt es wenig, dass in dieser Situation eventuell noch 15% freier Platz verteilt auf der Platte da ist. Wenn jetzt ein Prozess (z.B. Update) läuft der btrfs beim Aufräumen stört, sitzt man in der Falle und der Prozess scheitert weil er nichts mehr Schreiben kann.
Hilfe gibts hier
Fragmentierung einzelner Dateien ?
Dateien in die regelmäßig Ergänzungen oder Änderungen geschrieben werden, neigen dazu unter btrfs stark zu fragmentieren. Das ist Prinzip-bedingt wegen CopyOnWrite und “kein Fehler”.
Welche Dateien kommen in Frage ?
- Logdateien
- Datenbanken
- und womöglich andere Spezialitäten
Was das Internet sagt:
- Fragmentierung spielt bei SSDs überhaupt keine Rolle
- Andere dagegen sprechen von drastischen Zahlen. In einem Beitrag ist von 17k extends die Rede.
Also eine Datei die in 17.000 Fragmente zersplittert ist.
Da nutzt dann bestimmt die best SSD nix wenn die Datei gelesen werden muss
Selber untersuchen macht schlau
Wie findet man fragmentierte Dateien ?
Da gibt es ein Program namens filefrag das für einzelne Dateien anzeigt, aus wie vielen Teilen sie bestehen.
Das einzige Problem dabei ist, dass dieses Programm für ext4 geschrieben wurde. Es “soll” aber auch für andere Dateisysteme funktionieren. Wir werden sehen 
zsh, filefrag, egrep … ein Einzeiler halt
for N in /var/**/*(.); do filefrag $N; done|egrep ': ([0-9]{3,}|[6-9][0-9]) extents found' >> /opt/defrag.txt
-
Untersuche mit
filefragjede Datei*(.)die in irgendeinen Teil/**/von/varliegt:
for N in /var/**/*(.); do filefrag $N; done -
Filtere
|egrepdiejenigen aus die mehr als 100([0-9]{3,}oder 60-99|[6-9][0-9])extends haben
|egrep ': ([0-9]{3,}|[6-9][0-9]) extents found'
35k extends - Das ist heftig !
Der erste Streich:
- /var/nosnap/VMs/manjaro19/manjaro19.vdi: 34999 extents found
compsizebestätigt das aber. Un die VM war nichtmal oft im Einsatz
compsize /var/nosnap/VMs/manjaro19/manjaro19.vdi
Processed 1 file, 35036 regular extents (35036 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 76% 10G 13G 13G
none 100% 8.9G 8.9G 8.9G
zstd 26% 1.1G 4.2G 4.2G
Also defreagmentieren wir die Datei jetzt am besten schnell
Warning: most Linux kernels will break up the ref-links of COW data
(e.g., files copied with 'cp --reflink', snapshots) which may cause
considerable increase of space usage. See btrfs-filesystem(8) for
more information.
Es ist klar dass wir dabei die Verbindung zu den Snapshots verlieren, aber auf diesem subvolume gibt es keine snapshots
sudo btrfs filesystem defrag
var/nosnap/VMs/manjaro19/manjaro19.vdi
Dann zur Kontrolle nochmal anschauen:
compsize /var/nosnap/VMs/manjaro19/manjaro19.vdi
Processed 1 file, 54678 regular extents (54678 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 64% 8.5G 13G 13G
none 100% 6.7G 6.7G 6.7G
zstd 27% 1.7G 6.4G 6.4G
55k extends - Das kann ja wohl nicht sein ?
Also erstmal sieht es so aus als ob das genau das Gegenteil bewirkt hätte. Aber bei genauerer Betrachtung wird sichtbar, dass die Datei jetzt deutlich besser komprimiert ist als vorher.
Und da liegt auch das “scheinbare” Problem. Die Datei ist nicht wirklich fragmentiert im klassischen Sinn. Jedes einzeln komprimierte Häppchen zählt wohl als ein Fragment.
Wenn man also Kompression eingeschaltet hat, (was diese VM von 13G auf 8.5G drückt) kann man nicht so einfach die Erbsen(Extends) zählen.
Bei mir sind tatsächlich danach mehr als 2.5G im Dateisystem frei geworden 
969 extends - Eine zerstückelte Logdatei !
Der 2.Streich:
- /var/log/snapper.log: 969 extents found (das war gestern)
compsize bestätigt das heute (sogar etwas mehr)
compsize snapper.log
Processed 1 file, 1022 regular extents (1022 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 61% 3.9M 6.5M 4.0M
none 100% 1.5M 1.5M 1.5M
zstd 49% 2.4M 4.9M 2.5M
Also schnell mal defragmentieren
sudo btrfs filesystem defrag snapper.log
compsize snapper.log
Processed 1 file, 1022 regular extents (1022 refs), 0 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 61% 3.9M 6.5M 4.0M
none 100% 1.5M 1.5M 1.5M
zstd 49% 2.4M 4.9M 2.5M
Das ist jetzt aber ernüchternd. Anscheinend hat das Defragmentieren garnix gebracht. Offensichtlich ist die Datei nicht wirklich fragmentriert, sondern wie die VM einfach nur gut komprimiert. Die Aussage “das sind soundsoviel Bruchstücke” scheint also recht wenig zu bedeuten. Um zu wissen, ob das wirklich relevant ist, müsste man schon wissen, wo diese Buchstücke liegen. Sind sie alle in einem oder 2 “chunks”, dann ist die fragmentierung bedeutungslos weil alles gleichzeitig im Speicher vorliegt. Im Gegenteil, zusammen mit der Kompression ist die Datei vermutlich schneller gelesen, als wenn sie unkomprimiert an einem Stück gelesen werden könnte.
Und der 3. folgt sogleich
Ergebnisse:
- betroffen sind VMs ganz heftig, aber eventuell ist die Datei nur halt sehr groß und sehr gut komprimiert (zstd:9). Ausserdem liegen die “Fragmente” in diesem Fall vermutlich nacheinander im selben “chunk” und werden somit extrem schnell gelesen
- Auch Logdateien können ganz heftig fragmentiert sein. Das stellt sich bei mir aber auch als reiner Bluff heraus und stammt offensichtlich nur von der Kompression. Der Zugriff auf mehrere Generationen von Logs ist weit wertvoller als die möglichen Probleme
Wenn die Größe der Logs begrenzt ist, scheint btrfs die Fragmentierung hier in einem vernünftigen Rahmen zu halten. Mit einer SSD also kein Problem
Randbedingungen
Die Randbedingungen für btrfs sind sicher nicht bei jedem gleich. Bei meiner Installation ist einiges btrfs-freundlich
- 2 Partitionen auf 2 verschiedenen SSDs im btrfs volume als RAID2
- Die Kompression des volume ist auf zstd:9 eingestellt (langsam beim schreiben, aber hohe kompression)
- Das Volume ist nur zu weniger als 50% voll ! (Da hat btrfs platz zum atmen)
- Ich mach jedes manjaro update zeitnah (keine sammelupdates)
- snapper löscht die snapshots die es macht (zeitgesteuert).
- Die snapshots beginnen stündlich und enden in Stufen nach 3 Monaten. (keine älteren Snapshots !!!)
- Der Rechner hat 48GB RAM (viel Puffer beim lesen, kein swapping)
- Die CPU verarbeitet 16 Threads
- Das system hat bestimmt schon 30 oder mehr Rollbacks erlebt (Cleanup nicht vergessen)
habe ich weitere Untersuchungen eingestellt. Der Thread soll nur andere davon abhalten den Messergebnissen zu hohe Bedeutung zuzumessen.