Sebastian
YaBB God
 Offline
Einträge: 812
|
 |
Btrfs Speicherplatz belegung Grafisch darstellen
« am: 26. November 2025, 09:14:43 »
|
|
Einleitung:
Hallo Suletuxe,
ich habe mich wieder etwas tiefer mit dem Dateisystem Btrfs beschäftigt. Dieses Mal wollte ich herausfinden, wie mein System Daten und Dateien physisch auf dem Datenträger allociert. Ich wollte besser verstehen, wie ein Copy-on-Write (COW) Dateisystem im Laufe der Zeit fragmentiert und ob das für mich relevant wird, vor allem weil ich plane, Btrfs auch auf HDDs einzusetzen.
TLDR;
Ich habe mir per btrfs-heatmap die physische Belegung meines Laptops anzeigen lassen, um Fragmentation, Chunk-Verhalten und die Arbeitsweise von Btrfs über die Zeit zu beobachten. Zusätzlich habe ich mir einen systemd-Service samt Timer gebaut, der täglich eine Heatmap erzeugt.
Hauptteil:
Um mir wortwörtlich ein besseres Bild zu machen, habe ich mein Btrfs-Dateisystem mit dem Tool btrfs-heatmap grafisch darstellen lassen.
Bild Dateisystem Übersicht:
Bild Dateisystem Übersicht
Die obere Grafik wird über eine Hilbert-Kurve dargestellt. Diese Kurve ermöglicht es, lineare Daten platzsparend in einem Quadrat abzubilden. Die erste physische Adresse liegt unten links, schlängelt sich dann nach oben und endet unten rechts.
Zur Illustration:
Die Farbbedeutungen in der Übersicht:
- Blau = Metadaten
- Weiß = allocierter Speicher
- Schwarz = unallocierter Speicher
Das dargestellte Bild zeigt Btrfs im SSD-Modus. Hier kümmert sich Btrfs weniger darum, Daten zusammenhängend abzulegen, da Fragmentation auf SSDs praktisch keine Rolle spielt. Besonders gut erkennbar ist, dass sich Metadaten am Anfang des Datenträgers sammeln. Dieser Bereich ist bereits so stark gefüllt, dass Btrfs etwa in der Mitte der Platte einen neuen Metadaten-Chunk allociert und begonnen hat, ihn zu beschreiben.
Man sieht außerdem im oberen linken Bereich größere unallocierte Lücken innerhalb bereits allocierten Regionen. Vermutlich hatte ich dort große Dateien abgelegt, die einen gesamten Chunk (ca. 1 GiB) vollständig gefüllt hatten und beim Löschen wieder komplett freigegeben wurden. Da Btrfs versucht, Chunks möglichst vollständig zu füllen, bevor neue angelegt werden, entstehen solche großen freien Bereiche.
Wichtig ist die Unterscheidung zwischen Chunk-Allocation und Datei-Fragmentation. Chunk-Lücken bedeuten nicht automatisch, dass Dateien fragmentiert sind. Innerhalb eines Chunks kann eine Datei dennoch an vielen Stellen verteilt liegen oder sich sogar über mehrere Chunks erstrecken. Für eine möglichst zusammenhängende Ablage sorgt btrfs filesystem defragment. Das habe ich in einem eigenen Beitrag genauer beschrieben:
BTRFS – balance vs defragment oder was sind diese Chunks und Extents für …
Zum Vergleich habe ich die Metadaten-Chunks vom Anfang und aus der Mitte der Platte im Detail aufgenommen:
Metadaten-Chunk 1
Metadaten-Chunk 2
Was die Farben im Detail bedeuten, steht in der btrfs-heatmap-Dokumentation
Gerade Metadaten-Chunks fragmentieren stark. Das ist logisch, da dort die meisten Änderungen stattfinden. Daten selbst bewegen sich bei einem COW-Dateisystem dagegen kaum – es werden eher neue Extents angehängt. Metadaten müssen jedoch ständig aktualisiert werden, um auf neue Daten zu zeigen.
Um die Entwicklung des Dateisystems über längere Zeit zu beobachten, habe ich mir einen systemd-Service mit Timer gebaut, der täglich eine neue Heatmap erstellt. Sobald ich genug Bilder gesammelt habe, werde ich daraus ein Daumenkino basteln, um Chunk-Bewegungen sichtbar zu machen.
Systemd Service:
Hier der systemd-Service (Template) für die tägliche Heatmap:
[Unit]
Description=Generiert eine Heatmap eines Btrfs Dateisytems unter / gemountet ist.
[Service]
Type=oneshot
WorkingDirectory=/home/%i/Bilder/btrfs-heatmap
Group=%i
ExecStart=/usr/bin/btrfs-heatmap /
ProtectSystem=strict
ReadWritePaths=/home/%i/Bilder/btrfs-heatmap
PrivateTmp=true
PrivateDevices=true
LockPersonality=true
ProtectClock=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectControlGroups=true
RemoveIPC=true
RestrictSUIDSGID=true
RestrictRealtime=true
SystemCallFilter=@system-service @basic-io @file-system ~@privileged
IPAddressDeny=any
NoNewPrivileges=true
RestrictFileSystems=btrfs
|
|
Datei: /etc/systemd/system/btrfs-heatmap@.service
[Unit]
Description=Startet 1x am Tag den btrfs-heatmap@.service
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
|
|
Datei: /etc/systemd/system/btrfs-heatmap@.timer
Zur Nutzung legt man im Heimatverzeichnis den Ordner $HOME/Bilder/btrfs-heatmap an. Dieser ist der einzige Pfad, in dem der Service schreiben darf. Anschließend aktiviert man den Timer. Hinter dem @-Zeichen im Servicenamen steht der Benutzername, damit systemd die Pfade korrekt ersetzt.
So wüdre der Timer aktiviert werden:
# Falls die zwei Dateien grade Frisch angelegt worden sind einmal Daemon neu starten
sudo systemctl daemon-reload
sudo systemctl enable --now btrfs-heatmap@sebastian.timer
|
|
Der erste lauf würde dann am nächsten Tag statfinden. Möchte man gleich ein Bild Anfertigen dann einmal bitte den Service direkt starten:
sudo systemctl start btrfs-heatmap@sebastian.service
|
|
Fazit:
Die Heatmaps geben ein sehr anschauliches Gefühl dafür, wie Btrfs intern mit Chunks, Metadaten und Daten arbeitet. Gerade langfristige Beobachtungen zeigen gut, welche Bereiche sich dynamisch verändern. Der tägliche systemd-Export erleichtert das enorm und erlaubt spannende Auswertungen über Wochen oder Monate.
Quellenangabe:
LG
Sebastian
|
| « Letzte Änderung: 26. November 2025, 09:17:22 von Sebastian » |
 Gespeichert
|
Wo die digitale Kultur blüht, nutzen Angreifer Emotionen, Gewohnheiten und Markenbindung aus. Der Schutz beginnt nicht mit Technik, sondern mit Bewusstsein. Wer sich informiert, vorsichtig klickt und sichere Tools nutzt, kann auch unbeschwert an der Digitalkultur teilnehmen.
|
|
|
Autor
