| 2 |
allgemeine Kategorie / Tutorials / Re:BTRFS Generation was ist das? Und wie hilft dies bei inkrementelle Backups? |
am: 17. Dezember 2025, 11:43:24 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Der Btrfs Generation-Zähler lässt sich auch sehr gut mit Konzepten aus Git vergleichen. Gerade für Nutzer, die regelmäßig mit Git arbeiten, wird damit schnell klar, warum dieser Mechanismus so mächtig ist.
In Git beschreibt jeder Commit einen eindeutigen Zustand des Repositories. Ein Commit repräsentiert nicht nur „den aktuellen Stand“, sondern enthält implizit auch die komplette Historie bis zu diesem Punkt. Ähnlich verhält es sich bei Btrfs mit der Generation-Nummer: Jede Generation beschreibt einen klar definierten Zustand des Dateisystems, inklusive aller vorherigen Änderungen (Ausser von nicht mehr Refernezierten Daten).
Man kann sich die Generation dabei wie einen fortlaufenden Commit-Zähler vorstellen. Während Git mit Hashes arbeitet, verwendet Btrfs eine monoton steigende Zahl. Das Prinzip ist jedoch vergleichbar: Alles, was nach Generation X passiert, entspricht in Git sinngemäß allem, was nach Commit X hinzugekommen ist.
Der Befehl btrfs subvolume find-new entspricht gedanklich einem sehr gezielten git diff. Statt zwei Commits miteinander zu vergleichen, sagt man Btrfs: „Zeige mir alle Änderungen seit Generation X.“ Das Dateisystem kann diese Frage exakt beantworten, weil jede Metadaten-Änderung mit einer Generation markiert ist. (Auch das gilt nur für noch Referenzierte Daten)
Auch btrfs send -p lässt sich direkt auf Git übertragen. Der Parent-Snapshot entspricht einem Basis-Commit, von dem aus ein inkrementeller Patch erzeugt wird. Btrfs send erstellt keinen heuristischen Vergleich, sondern ein exaktes Delta aller Extents mit einer höheren Generation als der Parent. In Git-Terminologie wäre das vergleichbar mit einem sauberen Patch, der ausschließlich die Änderungen seit dem letzten Commit enthält.
Ergebnisbewertung: Der Send-Stream ist deterministisch und frei von überflüssigen Daten, vergleichbar mit einem minimalen Commit-Diff.
Snapshots selbst kann man sich wie Branches vorstellen. Jeder Snapshot friert einen bestimmten Zustand – also eine konkrete Generation ein. Weitere Änderungen erhöhen die Generation, ohne den alten Zustand zu verändern. Genau wie bei Git bleibt ein alter Commit unverändert, egal wie sich der Branch weiterentwickelt.
Der große Unterschied zu ext4 wird mit dieser Analogie besonders deutlich. ext4 kennt weder Commits noch Diffs auf Dateisystemebene. Es gibt keinen globalen „Commit-Zähler“, der beschreibt, in welchem konsistenten Zustand sich das Dateisystem befand. Man arbeitet dort eher ohne Versionskontrolle, während Btrfs funktional einem versionierten Dateisystem ähnelt.
Änlich deshalb weil anders als wie bei git wo zu jeden Commit zurückgerollt werden kann – btrfs nur zu den Generationen zurückspringen kann die mithilfe eines Snapshots festgehalten wurden. Da ohne einen Snapshot Daten die nicht mehr Rferenziert werden im Diff fehlen.
Für forensische Analysen ist dieser Vergleich besonders hilfreich. So wie man in Git exakt nachvollziehen kann, welcher Commit welche Änderung eingeführt hat, kann man bei Btrfs anhand der Generation rekonstruieren, ab wann bestimmte Daten existierten oder verändert wurden. Diese Nachvollziehbarkeit ist ein integraler Bestandteil des Dateisystems und kein nachträglich aufgesetztes Werkzeug.
Zusammengefasst lässt sich sagen: Der Btrfs Generation-Zähler ist konzeptionell näher an Git als an klassischen Dateisystemen. Wer Git versteht, versteht auch, warum Btrfs Änderungen präzise verfolgen, vergleichen und reproduzieren kann – und warum ext4 diese Fähigkeiten grundsätzlich nicht bieten kann.
Um es noch mal klar zu machen. Btrfs Visioniert nicht wie git, deshalb fehlen immer Daten die von keinen Snapshot oder Subvolumen mehr gehalten werden. Trotzdem lassen sich auf diese Art ein Zustand zwischen einen vorherigen Snapshot und den ist zustand vergleichen. Quasi was in der Ausgabe fehlt wurde bis dato gelöscht und was hinzugekommen ist, ist in der Ausgabe mit drin enthalten.
LG
Sebastian |
   |
| 3 |
allgemeine Kategorie / Tutorials / BTRFS Generation was ist das? Und wie hilft dies bei inkrementelle Backups? |
am: 15. Dezember 2025, 12:11:27 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Btrfs bringt im Vergleich zu klassischen Dateisystemen einige interne Mechanismen mit, die weit über reine Datenspeicherung hinausgehen. Einer davon ist der sogenannte Generation-Zähler (Generation Counter).
TLDR;
Jede Änderung an einem Btrfs-Dateisystem erhöht eine globale Generation-Nummer. Diese ermöglicht es, Änderungen exakt nachzuvollziehen, inkrementelle Sends effizient umzusetzen und den Zustand eines Subvolumes zu einem bestimmten Zeitpunkt reproduzierbar zu analysieren – ein Konzept, das ext4 grundsätzlich fehlt.
Hauptteil:
Der Btrfs Generation-Zähler ist ein monoton steigender Zähler, der bei jeder strukturellen Änderung des Dateisystems erhöht wird. Dazu zählen unter anderem:
- Schreiben oder Löschen von Dateien
- Metadatenänderungen wie Rechte, Zeitstempel oder Extent-Zuordnungen
Diese Generation wird sowohl im Dateisystem selbst als auch in Snapshots gespeichert. Ein Snapshot repräsentiert damit nicht nur einen inhaltlichen Zustand, sondern auch eine klar definierte Generation des Dateisystems.
Der entscheidende Vorteil gegenüber ext4 liegt darin, dass Btrfs Änderungen explizit versioniert. ext4 kennt zwar Zeitstempel und Journal-Mechanismen, aber keinen globalen, konsistenten Änderungszähler, der eine exakte Abgrenzung von „alles seit Zeitpunkt X“ erlaubt.
Btrfs nutzt diesen Mechanismus intern unter anderem für:
- Inkrementelle Backups mit btrfs send -p
- Analyse von Änderungen mit btrfs subvolume find-new
Damit wird nicht geraten oder heuristisch verglichen, sondern exakt anhand der Generation entschieden, welche Extents neu oder verändert sind.
Beispiele:
Angenommen, ein Subvolume @home hat aktuell folgende Generation:
btrfs subvolume show /home
|
|
Die Ausgabe enthält unter anderem:
Nach einigen Dateiänderungen ist die Generation auf 12080 gestiegen. Um alle Änderungen seit Generation 12045 aufzulisten, kann folgender Befehl verwendet werden:
btrfs subvolume find-new /home 12045
|
|
Das Ergebnis listet alle Dateien und Pfade auf, deren Extents seit dieser Generation neu angelegt oder verändert wurden. Intern wertet Btrfs dabei exakt die Generationen der Metadaten aus.
Ergebnisbewertung: Die Ausgabe ist vollständig und deterministisch, es gibt keine Fehlklassifikationen durch Zeitstempel oder Dateigrößen.
Genau dieses Prinzip nutzt auch btrfs send -p. Der Parent-Snapshot liefert die Referenz-Generation, und Btrfs sendet nur die Extents, deren Generation höher ist als die des Parent-Snapshots.
Ergebnisbewertung: Der Send-Stream enthält ausschließlich echte Änderungen, unabhängig von Dateinamen, Inodes oder Kopierwegen.
Fazit:
Der Generation-Zähler macht Btrfs zu einem nachvollziehbaren, versionierten Dateisystem. Für jede Generation lässt sich exakt bestimmen, in welchem Zustand sich ein Subvolume befunden hat. Das ist nicht nur für Backups relevant, sondern auch für forensische Rekonstruktionen ein enormes Plus: Es kann präzise nachvollzogen werden, was sich wann geändert hat.
ext4 bietet hierfür kein vergleichbares Konzept. Ohne globale Generationen bleibt dort nur eine indirekte Analyse über Zeitstempel oder Journaldaten, die weder vollständig noch reproduzierbar ist.
Btrfs liefert mit seinem Generation-Zähler eine zusätzliche Ebene der Datenintegrität und Nachvollziehbarkeit, die klassische Dateisysteme grundsätzlich nicht erreichen.
Quellenangabe:
LG
Sebastian |
| |
| 4 |
allgemeine Kategorie / Tutorials / Datei/Extent Referenzierung und wie man ein BTRFS Dedupliziert |
am: 07. Dezember 2025, 18:42:48 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Btrfs bietet als Copy-on-Write (CoW) Dateisystem die Möglichkeit, identische Datenblöcke in sogenannten Extents gemeinsam zu nutzen. In der Praxis entstehen diese „shared extents“ jedoch nicht immer automatisch. Genau hier setzen Deduplizierungswerkzeuge wie duperemove an, die doppelte Dateninhalte nachträglich identifizieren und Extents effizient zusammenführen.
TLDR; Btrfs kann Extents gemeinsam nutzen, macht dies jedoch nicht in allen Szenarien automatisch. Deduplizierer wie duperemove erkennen identische Inhalte und sparen effektiv Speicher, was bei klassischen Dateisystemen wie EXT4 technisch nicht möglich wäre.
Hauptteil:
Btrfs speichert Daten in Extents, also zusammenhängenden Datenbereichen. Wird eine Datei kopiert, kann das Dateisystem theoretisch erkennen, dass der Inhalt identisch ist und beide Dateien auf dieselben Extents verweisen. In der Realität hängt dieses Verhalten jedoch stark vom genutzten Tool und der Art des Schreibprozesses ab.
Typische Gründe für nicht-geteilte Extents:
- Beim Kopieren zweier Dateien mit identischem Inhalt erzeugen viele Programme neue Extents, anstatt bestehende zu verlinken. Die Entscheidung liegt beim Userspace-Tool, nicht bei Btrfs selbst. (Entwarnung gibt es beim Tool cp das als Standardverhalten [tt]--reflink=auto[/tt] verwendet. Das zum Kopieren auch viele Dateimanager intern verwenden.)
- Viele Programme erzeugen beim Speichern eine komplett neue Datei. Dadurch greift CoW nicht auf Blockebene, da das Programm die alte Datei löscht und eine neue schreibt.
- Auch Backup-Tools oder Build-Systeme schreiben häufig erneute Vollkopien, selbst wenn sich Inhalte kaum unterscheiden.
In solchen Fällen entstehen redundante Datenblöcke, die Btrfs nicht selbst zusammenführt. Btrfs bietet zwar Mechanismen wie reflinks oder Copy-on-Write, verlässt sich aber auf Userspace-Programme, um Extents gemeinsam zu nutzen. Ohne gezielten Eingriff bleiben doppelte Inhalte bestehen.
Genau an dieser Stelle hilft duperemove.
Das Werkzeug durchsucht gewählte Verzeichnisse, hashbasiert oder blockweise, ermittelt identische Datenbereiche und ersetzt diese durch gemeinsame Extents mittels reflink.
Damit wird die Datenlage nachträglich optimiert, ohne die Dateien selbst zu verändern.
Beispiele:
Im Folgenden ein klassischer Arbeitsablauf mit duperemove:
# Scan und Datenbank erzeugen (um nach den ersten lauf nur noch nach änderungen zu scannen) und anschliessende Deduplizierung
duperemove -r -d --hashfile=/var/tmp/duperemove.db /home/user
|
|
Fazit:
Deduplizierungstools wie duperemove sind auf Btrfs sinnvoll, weil identische Inhalte im Alltag nicht automatisch als gemeinsame Extents enden. CoW allein reicht nicht aus, da viele Anwendungen Dateien neu schreiben und dadurch unnötige Redundanz erzeugen. Besonders in Umgebungen mit vielen ähnlichen Daten – z. B. Backups, Build-Artefakte – spart eine Extent-basierte Nachoptimierung erheblich Speicher.
Klassische Journal-Dateisysteme wie EXT4 unterstützen keine Extent-basierte Deduplizierung. Die grundlegende Architektur verhindert das Teilen von Datenblöcken zwischen verschiedenen Dateien, wodurch Werkzeuge wie duperemove dort technisch nicht möglich sind.
Quellenangabe:
Nachtrag:
In meinen Alltag entstehen hauptsächlich nicht geteilte Extents wenn ich von einen anderen Datenträger Dateien in mein BTRFS kopiere und diese Dateien in anderen Verzeichnissen bereits vorhanden sind. Arbeite ich inhalb eines BTRFS können fast alle meine Tools referenzieren statt zu kopieren.
LG
Sebastian |
| |
| 5 |
allgemeine Kategorie / Allgemeine Diskussionen / KDE Plasma 6.8 nur noch mit Wayland-Sitzung |
am: 28. November 2025, 14:39:43 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Mit der Ankündigung, dass KDE Plasma ab Version 6.8 nur noch eine Wayland-Sitzung anbietet, steht erneut ein paradigmatischer Wechsel in der Linux-Desktopwelt bevor. Für viele Nutzer bedeutet das: X11 als native Sitzung fällt weg; die bisherige Kompatibilität läuft künftig über XWayland.
TLDR; KDE Plasma 6.8 (voraussichtlich 2026/2027) wird Wayland-only — X11-Sitzung entfällt, X11-Apps laufen über XWayland weiter.
Hauptteil:
Die Entwickler hinter KDE geben als Grund für den Verzicht auf die X11-Sitzung an, dass die parallele Pflege von X11 und Wayland den Entwicklungsaufwand unnötig erhöhe und Innovationen – etwa Verbesserungen bei Performance, Sicherheit und neuen Features – behindere.
Wesentliche Punkte der Umstellung:
- Die Plasma-X11-Sitzung wird mit Version 6.8 komplett entfallen.
- X11-Anwendungen bleiben nutzbar — über XWayland als Kompatibilitätsschicht.
- Für Distributionen mit Langzeit-Support (LTS), die Plasma in einer älteren Version mit X11 ausliefern, bleibt X11 länger erhalten. Als Beispiel wird AlmaLinux 9 genannt.
- Die Entwickler planen, Plasma-6.7 mit Bugfixes zu versorgen — der finale Drop von X11 erfolgt voraussichtlich Anfang 2027.
Aus Sicht eines technisch versierten Nutzers lohnt eine Bewertung folgender Aspekte:
- Kompatibilität älterer Anwendungen: Solange XWayland zuverlässig funktioniert, besteht kaum ein unmittelbarer Nachteil.
- Performance, Sicherheit & Modernisierung: Wayland bietet Vorteile bei modernen Grafik- und Eingabeszenarien; der Übergang kann langfristig einen saubereren, effizienteren Desktop bedeuten.
- Langfristige Planbarkeit: Wer X11 zwingend benötigt, sollte jetzt entweder eine LTS-Distribution wählen oder alternative Desktop-Umgebungen bzw. Workflows planen.
Beispiele:
- Ein Nutzer setzt auf eine nicht-Wayland-angepasste Qt- oder GTK-App unter Plasma — diese läuft nach der Umstellung weiterhin via XWayland.
- Eine Distribution mit LTS-Zyklus und Plasma-Version < 6.8 bleibt für (hoffentlich) mehrere Jahre zuverlässig nutzbar — etwa für produktive oder konservative Setups.
- Neue Installationen, bei denen Wayland bereits Standard ist (oft bei aktuellen Distros), profitieren direkt von besserer Wayland-Integration.
Fazit:
Der Schritt von KDE Plasma zu Wayland-only ist konsequent und passt zur generellen Entwicklung im Linux-Desktop-Umfeld. Für viele Nutzer bedeutet er zunächst wenig Änderung — X11-Programme laufen weiter, und Wayland ist ohnehin bei vielen Standard. Gleichzeitig ist der Schritt ein Signal für ein langfristiger planbares, moderneres System.
Für Anwender mit X11-abhängigen Workflows ist jetzt der Zeitpunkt, Alternativen zu prüfen oder auf LTS-Distributionen zu setzen.
Quellenangabe:
LG
Sebastian |
| |
| 6 |
allgemeine Kategorie / Tutorials / Weshalb btrfs send/receive gegenüber rsync bei einem btrfs vorzuziehen ist. |
am: 27. November 2025, 15:59:42 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Hallo Suletuxe,
heute möchte ich anhand eines einfachen Beispiels den Unterschied zwischen den Optionen -p und -c bei btrfs send erläutern. Beide Parameter greifen tief in das Replikationsverhalten ein, werden aber oftmals missverstanden. Besonders wenn bereits mehrere Snapshots existieren, lohnt sich ein genauer Blick auf das Zusammenspiel.
TLDR;
-p legt fest, welches Delta gesendet wird.
-c erlaubt das Klonen identischer Blöcke aus einem anderen Snapshot.
In Kombination prüft -c nur noch jene Blöcke, die durch -p überhaupt übertragen werden müssten.
Hauptteil:
Die folgende Ausgangslage beschreibt drei Snapshots aus zwei Subvolumes:
- H2: Parent-Snapshot von @home
- H3: Ziel-Snapshot von @home
- R3: Snapshot des Subvolumes @
Im Parent-Snapshot H2 besteht die Datei notes.txt aus Block A („Hallo Welt“) und Block B („Dies ist alt“).
Im Ziel-Snapshot H3 wurde Block B durch Block C („Dies ist neu“) ersetzt.
Snapshot R3 enthält Block A ebenfalls, jedoch in einer anderen Datei und in anderem Kontext.
1. Verhalten von btrfs send -p H2 H3
Mit dem Parent-Parameter wird ein reiner Delta-Stream erstellt. Btrfs vergleicht ausschließlich H2 und H3:
- Block A ist unverändert → keine Übertragung
- Block B wurde zu Block C ersetzt → Block C wird gesendet
- Andere Snapshots (z. B. R3) bleiben unberücksichtigt
Ergebnis: Nur Block C wird übertragen.
2. Verhalten von btrfs send -c R3 H3
Ohne Parent-Snapshot muss H3 vollständig übertragen werden. Zusätzlich versucht Btrfs jedoch, Blöcke aus dem Clone-Source R3 zu übernehmen:
- Metadaten von H3 müssen vollständig gesendet werden
- Block A existiert identisch in R3 → wird per Klon referenziert
- Block C ist neu → muss gesendet werden
Ergebnis: Metadaten + Block C, wobei Block A geklont wird.
3. Verhalten von btrfs send -p H2 -c R3 H3
Die Kombination beider Optionen führt zu einem zweistufigen Ablauf:
- -p bestimmt das Delta → einzig Block C ist relevant
- -c prüft nur diese Delta-Blöcke auf Klonbarkeit
- Block C existiert nicht in R3 → muss übertragen werden
- Block A wird nicht betrachtet, da es durch das Delta ausgeschlossen ist
Ergebnis: Identisch zu -p allein → nur Block C wird übertragen.
Beispiele:
# Delta-Send zwischen Snapshots
btrfs send --compressed-data -p H2 H3 | btrfs receive /mnt/backup
# Full-Send mit Klon-Quelle
btrfs send --compressed-data -c R3 H3 | btrfs receive /mnt/backup
# Kombiniert: Delta + Clone-Source
btrfs send --compressed-data -p H2 -c R3 H3 | btrfs receive /mnt/backup
|
|
Fazit:
btrfs send/receive ist bei Btrfs-Dateisystemen dem klassischen rsync klar überlegen. Das Verfahren arbeitet extentbasiert, nutzt Copy-on-Write intern aus, erhält Hardlinks sowie Snapshot-Strukturen und überträgt ausschließlich geänderte Blöcke. Dadurch entstehen kleinere, präzisere und wiederholbare Backup-Streams. Während rsync Dateien vergleicht und neu schreibt, arbeitet btrfs send dateisystemnah und optimal auf die Architektur abgestimmt.
Quellenangabe:
LG
Sebastian |
| |
| 7 |
allgemeine Kategorie / Tutorials / Btrfs Speicherplatz belegung Grafisch darstellen |
am: 26. November 2025, 09:14:43 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
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 |
| |
| 8 |
allgemeine Kategorie / Allgemeine Diskussionen / Erfahrungsbericht/Lernprozess Tonaufnahme mit PipeWire |
am: 22. November 2025, 11:54:04 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Hallo Suletuxe,
ich erweitere aktuell mein Verständnis rund um digitale Tonaufnahmen. Ausgelöst wurde das Ganze, weil ich das Audiosignal meines Notebooks für ein anderes Gerät aufzeichnen wollte. Damit ich nicht blind eine Aufnahme starte, habe ich mich zuerst mit den Grundlagen beschäftigt. Mein Ziel war eine Aufnahme in 3x bis 4x facher Geschwindigkeit, die ich anschließend wieder auf Normaltempo dehnen kann.
TLDR;
Ich erkläre hier kurz meinen Weg zu einer sauberen Aufnahme über PipeWire, warum ich 96 kHz als Sample Rate gewählt habe und wie ich das Signal direkt von der Quelle aufnehmen konnte.
Hauptteil:
Die Sample Rate beschreibt, wie oft pro Sekunde ein analoges Signal abgetastet wird. Für die Rekonstruktion einer Frequenz benötigt man mindestens das Doppelte ihrer höchsten vorkommenden Frequenz. Diese Regel nennt sich das Nyquist-Kriterium. Bei 48 kHz Sample Rate lassen sich daher Frequenzen bis etwa 24 kHz erfassen. Wird die Sample Rate zu niedrig gewählt, falten sich höhere Frequenzen in tiefere Bereiche zurück. Dieser Effekt ist als Aliasing bekannt.
Die Bittiefe bestimmt den Abstufungsgrad der Lautstärke (Amplitude). Je höher die Bittiefe, desto weniger Rundungsfehler entstehen. Diese Fehler machen sich als Quantisierungsrauschen bemerkbar. Da die menschliche Stimme grob im Bereich bis etwa 10 kHz liegt und typischerweise einen Dynamikumfang von ungefähr 50–70 dB hat, reicht eine Bittiefe von 16 Bit für Sprachaufnahmen üblicherweise aus.
Da ich meine Quelle mit vierfacher Geschwindigkeit abspielen wollte, erhöht sich die effektive Frequenzlage entsprechend. Um alle relevanten Frequenzen verlässlich abzudecken, muss ich die Aufnahme-Sample-Rate also ebenfalls erhöhen. Theoretisch würde eine Sample Rate von etwa 80 kHz reichen, praxisnah wählte ich 96 kHz als Standardwert mit etwas Luft nach oben.
Für die praktische Umsetzung musste ich verstehen, wie ich unter PipeWire das PCM-Signal direkt von der Quelle aufnehmen kann. Ein Node ist bei PipeWire ein Audiopunkt, der Daten liefert oder empfängt. Ein Sink nimmt Audio entgegen, ein Monitor-Port bietet Zugriff auf das Signal eines Sinks. Für meine Aufnahme wollte ich jedoch eine direkte Quelle (Node) und keinen gemischten Ausgang. Das ermöglicht eine stille Aufnahme, während das System weiterhin andere Sounds wiedergeben kann.
Die systemweite Sample Rate stellte ich über eine Drop-In-Konfiguration auf 96 kHz um. Anschließend nutzte ich pw-record aus dem Paket pipewire-audio, womit ich direkt die gewünschte Quelle abgreifen konnte.
Beispiele:
# pw-record mit direkter Quellenangabe
pw-record --target <Node-ID> --rate 96000 --channels 1 aufnahme.flac
# Beispielhafte Drop-In-Konfiguration für PipeWire (system.conf.d)
# /etc/pipewire/pipewire.conf.d/10-samplerate.conf
context.properties = {
default.clock.rate = 96000
default.clock.allowed-rates = [ 48000 96000 ]
}
|
|
Fazit:
Durch die moderne Informatonstechnologie ist es leicht möglich, sich auch in komplett neue Themenbereiche einzuarbeiten. Grundlagenwissen hilft enorm, um technische Entscheidungen bewusst zu treffen. Jetzt kann ich die Theorie in der Praxis weiter festigen und Erfahrungen sammeln. Sollte ich einzelne Aspekte falsch eingeordnet haben, freue ich mich über Hinweise, um mein mentales Modell weiter zu verfeinern.
Quellenangabe:
LG
Sebastian |
| |
| 9 |
allgemeine Kategorie / Installation, Einrichtung und Systempflege / yt-dlp benötigt eine externe JavaScript Runtime für den Youtube Support |
am: 14. November 2025, 19:08:12 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Bei einem Systemupdate ist mir eine neue optionale Abhängigkeit von yt-dlp aufgefallen. Die Einführung von yt-dlp-ejs hat einen technischen Hintergrund, der für viele Anwender relevant ist – insbesondere für Nutzer, die weiterhin zuverlässig YouTube-Videos extrahieren möchten.
TLDR;
Ab Version 2025.11.12 benötigt yt-dlp eine externe JavaScript-Runtime wie Deno für nicht-veralteten YouTube-Support. Das Paket yt-dlp-ejs bindet diese Runtime ein und sollte installiert werden, wenn YouTube-Unterstützung erforderlich ist.
Hauptteil:
Mit der Version 2025.11.12 hat das Projekt yt-dlp wesentliche Änderungen an der internen Verarbeitung der YouTube-Extraktion vorgenommen. Deno wird dabei als bevorzugte Laufzeitumgebung eingesetzt, da sie moderne JavaScript-Features vollständig unterstützt.
Für Arch-Linux-Nutzer wurde hierzu das Paket yt-dlp-ejs ergänzt. Dieses Paket fungiert als Schnittstelle zwischen yt-dlp und der externen Runtime. Bei Installation von yt-dlp-ejs wird Deno automatisch als Abhängigkeit eingerichtet. Erst damit steht der aktuelle, nicht-deprecated YouTube-Support zur Verfügung.
Für Nutzer, die regelmäßig YouTube-Inhalte extrahieren, ist die Nachinstallation daher sinnvoll. Zusätzlich empfiehlt sich die Installation als Abhängigkeit (--asdeps), damit die Paketverwaltung sauber bleibt und beim Entfernen von yt-dlp auch die zugehörigen Komponenten automatisch entfernt werden, sofern sie nicht anderweitig benötigt werden.
Beispiele:
Installation von yt-dlp-ejs als Abhängigkeit:
pacman -S --asdeps yt-dlp-ejs
|
|
Fazit:
Die Einführung einer externen JavaScript-Runtime in yt-dlp ist technisch nachvollziehbar und zukunftsorientiert. Für die meisten Anwender, die YouTube-Downloads nutzen, ist die Installation von yt-dlp-ejs empfehlenswert, da nur damit die vollständige Funktionalität erhalten bleibt.
Quellenangabe:
LG
Sebastian |
| |
| 10 |
allgemeine Kategorie / Allgemeine Diskussionen / SquashFS Tools 4.7.3 bis zu 1500x schneller und mit stdout Support |
am: 09. November 2025, 07:12:03 |
| Begonnen von Sebastian | Letzter Eintrag von Sebastian |
Einleitung:
Mit der Veröffentlichung von SquashFS Tools 4.7.3 hat sich einiges getan. Neben massiven Performance-Optimierungen bringt die neue Version auch praktische Erweiterungen für moderne Workflows mit. Besonders interessant ist die Möglichkeit, ein komplettes SquashFS-Dateisystem direkt an STDOUT zu streamen – also ohne temporäre Datei.
TLDR;
SquashFS 4.7.3 steigert die Leistung beim Lesen von Sparse Files um bis zu den Faktor 1500 und erlaubt nun, Dateisysteme direkt in eine Pipeline zu schreiben. Die Streaming-Funktion hat jedoch Einschränkungen und erfordert bei Bedarf eine Nachbearbeitung mit -fix.
Hauptteil:
SquashFS Tools 4.7.3 bringt eine deutliche Beschleunigung bei der Verarbeitung von Sparse Files. Durch die optimierte Nutzung der SEEK_DATA-Operation kann das Dateisystem Löcher in Dateien effizient überspringen. Dadurch ergibt sich je nach Struktur der Daten ein Leistungszuwachs von bis zu 240×. Wenn mehrere Datenblöcke als zusammenhängende Sparse-Bereiche erkannt werden, erhöht sich der Effekt auf bis zu 1500× im Vergleich zu früheren Versionen.
Neben diesen Optimierungen wurde auch die Funktionalität von mksquashfs erweitert. Das Tool kann nun Dateisysteme direkt an STDOUT streamen. Das ist vor allem in automatisierten oder speichersparenden Szenarien nützlich, beispielsweise für Backups oder Systemabbilder, die direkt über eine Pipeline übertragen werden sollen.
Einige technische Einschränkungen sind jedoch zu beachten:
- Beim Streamen ist keine Duplikaterkennung möglich.
- Der Superblock (Header) wird am Ende des Dateisystems geschrieben.
- Solche Abbilder können daher nicht direkt vom Kernel gemountet werden.
- unsquashfs kann diese Streams jedoch problemlos lesen.
Wer das gestreamte Abbild später mounten möchte, kann dies mit der neuen -fix-Option korrigieren. Sie verschiebt den Header an den Anfang der Datei und macht das Dateisystem wieder kernelkompatibel.
Beispiele:
Ein praktisches Beispiel für das neue Streaming-Feature:
# SquashFS-Dateisystem direkt nach STDOUT streamen und über ssh auf einem anderen Computer Speichern
mksquashfs directory - -stream | ssh phillip@192.168.178.1 dd of=image.sqfs
# Header nach vorn verschieben, um das Image mountbar zu machen
mksquashfs -fix image.sqfs
|
|
Fazit:
SquashFS Tools 4.7.3 zeigt, dass selbst ein ausgereiftes Dateisystem noch deutlich optimiert werden kann. Die Leistungssteigerung bei Sparse Files ist beeindruckend, und die neue Streaming-Funktion eröffnet flexible Anwendungsmöglichkeiten für fortgeschrittene Workflows.
Für meine Zwecke in der Langzeitarchivierung bleibt SquashFS weiterhin das bevorzugte Format. Die starke Kompression, eingebaute Deduplication und sequentielle Durchsuchbarkeit machen es klassischen Archivformaten wie tar, zip oder 7z weiterhin überlegen – vor allem, wenn es um Effizienz und Nachhaltigkeit geht.
Quellenangabe:
LG
Sebastian |
| |
Zurück zur Foren-Übersicht.
|
|
|
