Ein kurzes Memo
In der vergangenen Woche bin ich mehrfach über NetBSDs LFS (Log-Structured File System) gestolpert – erst in alten Unterlagen, dann in Diskussionen und schließlich in aktuellen Commits. Ich habe LFS zum ersten Mal Anfang der 2000er bewusst genutzt: NetBSD 2, ein Dual-Socket-Pentium-II-System mit 266 MHz, LFS als Root-Filesystem. Abstürze waren damals nicht ungewöhnlich und ein FFS-fsck gehörte fast zum Alltag. Umso mehr fiel LFS auf – durch schnelle Schreiboperationen, sehr kurze Recovery-Zeiten und gelegentlich auch einen Cleaner, der das System gut ausgelastet hat.
Vielleicht deshalb war ich jetzt aufmerksam: Im November 2025 ist im LFS-Subsystem deutlich mehr passiert, als man erwarten würde. Eine kurze Recherche zeigt eine ungewöhnlich aktive Phase.
LFS – Log-Structured File System wurde Anfang der 1990er von Mendel Rosenblum und John K. Ousterhout an der University of California, Berkeley entwickelt.
Grundidee: Alle Änderungen – Daten, Inodes, Metadaten – werden sequentiell in ein Log geschrieben. Nichts wird überschrieben, alles wird neu angefügt. Das ermöglicht hohe Schreibraten und eine sehr schnelle Recovery nach Abstürzen.
Kerndesign:
- sequentielle Writes statt zufälliger Block-Aktualisierungen
- Crash-Recovery durch einfachen Segment-Scan
- ein Cleaner-Prozess reorganisiert im Hintergrund das Dateisystem
- alte Blöcke werden erst später freigegeben
Herausforderungen: LFS steht und fällt mit einem gut funktionierenden Cleaner. Ungünstige Segmentfüllstände, Race Conditions oder inkonsistente Inode-Zustände wirken sich schnell spürbar auf das gesamte System aus.
NetBSDs Besonderheit: NetBSD ist eines der wenigen Unix-Systeme, das LFS vollständig im Kernel implementiert, inklusive eines aktiven Cleaner-Subsystems. Das macht NetBSD zu einem der letzten Orte, an denen LFS praktisch weiterentwickelt wird.
Literatur:
NetBSD – das portable, klare Unix
Ein freies, POSIX-konformes Unix mit Fokus auf Portabilität, klare Architektur und präzise Kernel-Implementierung.
Projektseiten:
- Offizielle Website: https://www.netbsd.org
- Dokumentation & Guides: https://www.netbsd.org/docs/
- NetBSD Internals Guide: https://www.netbsd.org/docs/internals/en/
- Source-Changelogs (täglich aktualisiert): https://mail-index.netbsd.org/source-changes/
- Repositories auf GitHub: https://github.com/NetBSD/src
Eigenschaften:
- läuft auf mehr Architekturen als jedes andere Unix
- modulare Kernel-Architektur
- robuste, konservative Entwicklungsphilosophie
Aktive Änderungen im November 2025
Neues Inode-Lebenszyklus-Flag (IN_DEAD)
Quelle: https://mail-index.netbsd.org/source-changes/2025/11/01/msg158797.html
Ein langjähriges Problem wurde strukturell gelöst:
IN_DEAD markiert nun eindeutig, wann eine Datei endgültig gelöscht ist.
→ zuverlässigere Cache-Zustände, weniger Race Conditions, stabilerer Cleaner.
Fix für doppelte Entfernung in der Cleaning-Queue
Quelle: https://mail-index.netbsd.org/source-changes/2025/11/03/msg158811.html
Einträge konnten zweimal aus lfs_cleanhd entfernt werden – eine seltene, aber schwer nachvollziehbare Panic-Ursache.
→ korrigierte Zustandsverwaltung, weniger unerwartete Cleaner-Fehler.
Neuer In-Kernel-Cleaner (lfs_kclean.c)
Quelle: https://mail-index.netbsd.org/source-changes/2025/11/06/msg158840.html Ein bedeutender Umbau:
- eigene Datei für die Cleaner-Logik
- konsolidierte Funktionen
- klarere Verantwortlichkeiten
- bessere Testbarkeit
→ Ein struktureller Fortschritt für das gesamte Subsystem.
Endlosschleifen beim Schreiben: jetzt „fail fast“
Quelle: https://mail-index.netbsd.org/source-changes/2025/11/10/msg158900.html → max. 3 Schleifen → Warnung → 10 Schleifen → definierte Panic statt stiller Hänger → bessere Diagnosefähigkeit, weniger unklare Lock-Situationen.
Remount-Fix für rw → ro
Quelle: https://mail-index.netbsd.org/source-changes/2025/11/17/msg159019.html Ein assert beim Lesen/Schreiben wurde korrigiert. → stabileres Umschalten in den Read-Only-Modus, wichtig bei Backups und Wartung.
Testsuite: klarer und realer
Quelle: https://mail-index.netbsd.org/source-changes/2025/08/27/msg157830.html → 32-Bit-LFS: expected fail → 64-Bit-LFS: skip → realistischere Erwartungswerte, bessere Diagnostik.
Fazit
Ein ungewöhnlich aktiver Monat für LFS:
- Altlasten bereinigt
- Cleaner-Logik strukturell modernisiert
- Testsystem erweitert und klarer gemacht
- Debug-Ausgaben verbessert
- transparenter Umgang mit Schwächen
Das LFS-Subsystem zeigt damit deutlich mehr Bewegung als erwartet – und liefert ein gutes Beispiel dafür, wie NetBSD seine technischen Wurzeln pflegt und gleichzeitig weiterentwickelt.
NetBSD läuft zuverlässig auch auf sehr schwacher Hardware. Mit FFS/WAPBL gibt es zwar seit Jahren ein stabiles Metadaten-Journalling, aber LFS bietet – endlich wieder stabil? – eine starke Alternative für Workloads mit hohem sequentiellen Schreibanteil, etwa:
- Block-Storage-Backends
- Logging- oder Telemetrie-Pipelines
- dedizierte Datenvolumes mit Write-Optimierung
Gerade heute wieder relevant: Durch das sequentielle Schreibmodell lässt sich die Anzahl der Schreibzyklen auf SSDs massiv reduzieren – ein Vorteil, der immer wichtiger wird.
Ich bleibe gespannt und werde in nächster Zeit einige praktische Versuche damit unternehmen.
Bildnachweis: Der BSD-Daemon („Beastie“) ist ein urheberrechtlich geschütztes Maskottchen von Marshall Kirk McKusick (© 1988 Marshall Kirk McKusick, All Rights Reserved). Die im Beitrag verwendete Darstellung ist eine KI-generierte Interpretation und kein offizielles Artwork. Sie dient der redaktionellen Illustration im Kontext von BSD-Technologien.