Software::Distributionen::BSD::DragonFly
DragonFly BSD: Hammer2 bekommt fsck
Eine Neuentwicklung von Tomohiro Kusumi erlaubt es, die Konsistenz des Hammer2-Dateisystems zu überprüfen. Notwendig ist das allerdings nicht, denn die Entwickler versprechen vom Design her, dass ihr System nie inkonsistent werden kann.
Dragonfly BSD
Das vom
DragonFly-Initiator Matthew Dillon unter dem Namen »Hammer« vorgestellte Dateisystem stellt ein hochverfügbares 64-Bit-Clusteringsystem dar. Zu den Stärken der auf B-Bäumen beruhenden Neuentwicklung zählen Schnappschüsse, eine Verlaufsaufzeichnung sowie die Möglichkeit, Fehler direkt bei der Einbindung (mount) des Systems zu korrigieren. So ist es nach einem Systemabsturz beispielsweise möglich, das Dateisystem ohne eine vollständige Überprüfung wieder in Betrieb zu nehmen.
Das Dateisystem wurde primär für DragonFly BSD entwickelt und unter anderem als Alternative zu ZFS angepriesen. Seit Anfang 2012 arbeitet Dillon an einem Nachfolger, der den Namen Hammer2 trägt und unter anderem eine transparente Kompression mittels LZ4 und zlib anbieten soll. Weitere neue Funktionen von Hammer2 umfassen eine Deduplizierung von Daten, schnellere Wiederherstellung von Inhalten, bessere Snapshotmöglichkeiten und eine Unterstützung von Booting.
Nachdem Hammer2 im Rahmen des Google Summer of Code 2013 unter anderem um eine Kompression erweitert wurde und in DragonFly 3.8 im Jahr 2014 als erste Testversion vorlag, wurde das Dateisystem in DragonFly BSD 5.0 offiziell. DragonFly BSD 5.2 und DragonFly BSD 5.4 fügten Hammer2 mehrere Korrekturen hinzu und stabilisierten das Dateisystem weiter. Mitte des vergangenen Jahres wurde Hammer2 als das Standarddateisystem für DragonFly BSD 5.6 auserwählt.
Ein Manko von Hammer2 – zumindest aus einer psychologischen Sicht – war das Fehlen eines Werkzeugs, das die Konsistenz des Systems prüfen konnte. Die Entwickler argumentierten mit dem Umstand, dass Copy-On-Write-Dateisysteme per Design nie inkonsistent werden können. Bei Systemen wie Hammer2, ZFS oder Btrfs werden geänderte Blöcke nicht überschrieben, sondern zunächst vollständig an einen freien Platz kopiert. Danach werden Verweise auf den Block in den Metadaten in einer Transaktion aktualisiert. Alte Metadaten und Blöcke werden dabei nicht gelöscht, sondern dem jeweiligen Speicherabbild zugeordnet.
Um die Nutzer zu beruhigen, hat nun Tomohiro Kusumi trotz allem ein neues Werkzeug vorgestellt, das in der Lage ist die Konsistenz des Systems zu prüfen. »fsck_hammer2« ist in der Lage die Konsistenz zu überprüfen und bei einem Fehler zu warnen. Eine Reparatur ist im Moment nicht möglich. Ob diese Funktion in der Zukunft kommt, gab der Entwickler nicht bekannt.
){kind=logo}
