Die kurze Antwort änderte sich, als die Community ZimaOS testete
Die ersten Antworten behandelten ZimaOS als minimales, applianceartiges System ohne herkömmlichen Paketmanager. Sie rieten davon ab, davon auszugehen, dass apt install oder dauerhafte Änderungen am Basissystem verfügbar sein würden. Docker und eine virtuelle Debian- oder Ubuntu-Maschine wurden als sauberere Isolationsgrenzen vorgeschlagen.
Spätere praktische Prüfungen brachten eine wichtige Korrektur: Ein Teilnehmer fand auf einem ZimaCube bereits /usr/bin/mergerfs und mergerfs-fusermount, während keine SnapRAID-Binärdatei gefunden wurde. Ein anderer Teilnehmer stellte beim Debugging eines Boot-Race-Problems fest, dass es sich bei dem enthaltenen mergerfs um eine ältere Version handelte. Das Ergebnis war also nicht „eine native Installation ist unmöglich“, sondern „manuelle Änderungen am Host werden nicht unterstützt und sind versionsabhängig“.
Manuelle Binärdateien funktionierten, brachten aber Aktualisierungsrisiken mit sich
Ein Nutzer erstellte unter WSL2 ausführbare Dateien, kopierte sie zu ZimaOS und berichtete von einer funktionierenden Konfiguration mit zwei Datenfestplatten und einer Paritätsfestplatte. Der Maintainer von mergerfs merkte an, dass statische Builds die manuelle Bereitstellung vereinfachen können, das Verhalten in Containern jedoch davon abhängt, ob die Laufzeitumgebung ausreichend Root-Rechte besitzt, um den FUSE-Mount wie erforderlich bereitzustellen.
In den Antworten der Community wurde wiederholt darauf hingewiesen, dass das Kopieren von Binärdateien in ein systemähnliches unveränderliches System zusätzlichen Wartungsaufwand verursacht. OTA-Updates können manuelle Änderungen ersetzen oder mit ihnen in Konflikt geraten, und die von der KI generierten Linux-Anweisungen enthielten während der Experimente des Nutzers Fehler.
Die Community entwickelte eine systemd-sysext-Schicht
Daraufhin veröffentlichte ein Mitwirkender ein gemeinschaftliches systemd-sysext-Projekt für ZimaOS. Es sollte mergerfs und SnapRAID als separate Erweiterungsschicht hinzufügen, statt das schreibgeschützte Basissystem direkt zu verändern.

Ein kontrollierter Test mit einem ZimaCube Pro bestätigte, dass die Schicht geladen wurde, mergerfs 2.42.0 und SnapRAID 14.5 bereitstellte und einen temporären mergerfs-Pool einbinden konnte. Der Tester erstellte eine Datei über den Pool-Pfad und überprüfte, dass sie vor dem sauberen Aushängen auf dem zugrunde liegenden Zweig erschien.
Dieser Test umfasste keinen vollständigen SnapRAID-Test von Parität und Wiederherstellung. Der Tester deaktivierte außerdem die standardmäßigen Timer und Dienste, bevor er etwas konfigurierte, damit diese nicht versehentlich auf echten Festplatten aktiv werden konnten.
Zwei Boot-Race-Probleme wurden gefunden und behoben
Nach einem Neustart stellte ein Nutzer fest, dass der Pool manchmal fehlschlug, während ein späterer manueller Start erfolgreich war. Der Autor der Erweiterung identifizierte zwei getrennte Race-Probleme. Erstens erkannte die ursprüngliche Prüfung die ältere, vom Basissystem bereitgestellte mergerfs-Binärdatei und startete den Pool, bevor die neuere Binärdatei der Erweiterung eingebunden war. Die überarbeitete Prüfung suchte nach SnapRAID, das ausschließlich von der Erweiterung bereitgestellt wurde.
Zweitens konnte mergerfs Erfolg melden, bevor die physischen Zweigfestplatten eingebunden waren, wodurch ein leerer Pool entstand, der den später eintreffenden Speicher verbarg. Eine einfache Schleife mit Restart=on-failure konnte diesen Zustand „erfolgreich, aber leer“ nicht erkennen. Das Projekt fügte explizite Prüfungen hinzu, die auf das Einbinden jedes Zweigs warten und den Aufbau des Pools über einem fehlenden Zweig verweigern.
Der Autor berichtete nach diesen Änderungen von einer Überprüfung nach einem Kaltstart unter ZimaOS 1.6.1. Ein Nutzer mit einem Gehäuse vom Typ TerraMaster mit vier Festplatten berichtete ebenfalls, dass der Pool schließlich erschien, nachdem das Einbinden der Festplatten fast eine Minute gedauert hatte.
Die Sicherheit von SnapRAID erfordert weiterhin eine Prüfung durch den Betreiber
Die Erweiterung enthielt einen Löschschwellenwert, der die Synchronisierung stoppen sollte, wenn unerwartet viele Dateien gelöscht wurden. Ein späterer Nutzer fragte, wie dieser Schwellenwert überschrieben werden kann, nachdem er absichtlich Tausende von Dateien entfernt hatte. Der Thread beantwortete diese betriebliche Frage nicht abschließend.
Wer das Projekt bewertet, muss vor dem Aktivieren automatisierter Jobs die Zweigpfade, Paritätspfade, Timer, Löschschwellenwerte und den Speicherort der Anwendungsdaten prüfen. Eine erfolgreiche Prüfung der Binärdateien oder ein erfolgreicher mergerfs-Mount beweist nicht, dass die Wiederherstellung der Parität für einen Produktivdatensatz getestet wurde.
Support-Grenze
Dies ist eine von der Community entwickelte erweiterte Integration und keine von IceWhale unterstützte ZimaOS-Speicherfunktion. Docker, eine vollständige Linux-VM, statische Binärdateien und sysext weisen jeweils unterschiedliche Berechtigungs- und Persistenzeigenschaften auf. Das stärkste Ergebnis des Threads ist die getestete Erweiterungsmethode, sie sollte jedoch weiterhin mit temporär bereitgestelltem Speicher geprüft werden, bevor Live-Daten eingebunden werden.
FAQ
Ist mergerfs bereits in ZimaOS enthalten?
Ein Teilnehmer bestätigte eine mergerfs-Binärdatei auf seinem ZimaCube. Später stellte sich im Thread heraus, dass es sich bei dieser Version des Basissystems um eine ältere Version handelte. Ihr Vorhandensein garantiert daher keine Kompatibilität mit einer modernen Konfiguration.
Wurde die Wiederherstellung mit SnapRAID vollständig getestet?
Nein. Der kontrollierte Test bestätigte die Installation und einen temporären mergerfs-Pool, brach jedoch ausdrücklich vor einem vollständigen Test von SnapRAID-Parität und -Wiederherstellung ab.
Warum reichte das Warten auf einen fehlgeschlagenen Dienst nicht aus?
Ein Race-Problem konnte einen leeren Pool mit einem erfolgreichen Exit-Code erzeugen. Da dies kein Fehler war, konnte eine Regel für den Neustart bei Fehlern allein den Zustand übersehen.
