Krótka odpowiedź zmieniła się, gdy społeczność przetestowała ZimaOS
Pierwsze odpowiedzi przedstawiały ZimaOS jako minimalistyczny system w stylu appliance, bez tradycyjnego menedżera pakietów. Odradzano zakładanie, że dostępne będą polecenie apt install lub trwałe modyfikacje bazowego systemu operacyjnego. Docker oraz maszyna wirtualna z Debianem lub Ubuntu zostały zaproponowane jako lepsze granice izolacji.
Późniejsze testy praktyczne wprowadziły ważne uzupełnienie: jeden z uczestników znalazł pliki /usr/bin/mergerfs i mergerfs-fusermount już obecne na ZimaCube, ale nie znaleziono pliku binarnego SnapRAID. Inny uczestnik ustalił, że dołączony mergerfs był starszą wersją podczas debugowania wyścigu przy uruchamianiu systemu. W rezultacie nie chodziło o to, że „instalacja natywna jest niemożliwa”, lecz o to, że „ręczne zmiany na hoście nie są obsługiwane i zależą od wersji”.
Ręczne pliki binarne działały, ale wiązały się z ryzykiem aktualizacji
Jeden z użytkowników zbudował pliki wykonywalne w WSL2, skopiował je do ZimaOS i zgłosił działającą konfigurację z dwoma dyskami danych oraz jednym dyskiem parzystości. Opiekun projektu mergerfs zauważył, że kompilacje statyczne mogą uprościć ręczne wdrażanie, ale działanie kontenera zależy od tego, czy środowisko uruchomieniowe ma wystarczające uprawnienia root, aby udostępnić wymagane montowanie FUSE.
W odpowiedziach społeczności wielokrotnie ostrzegano, że kopiowanie plików binarnych do systemu w stylu niezmiennego systemu operacyjnego powoduje dodatkowe obowiązki konserwacyjne. Aktualizacje OTA mogą zastąpić ręczne zmiany lub wejść z nimi w konflikt, a instrukcje dla Linuksa wygenerowane przez AI zawierały błędy podczas eksperymentów użytkownika.
Społeczność utworzyła warstwę systemd-sysext
Następnie jeden z kontrybutorów opublikował społecznościowy projekt systemd-sysext dla ZimaOS. Jego celem było dodanie mergerfs i SnapRAID jako oddzielnej warstwy rozszerzeń zamiast bezpośredniej modyfikacji systemu bazowego tylko do odczytu.
Kontrolowany test na ZimaCube Pro potwierdził, że warstwa została załadowana, udostępniła mergerfs 2.42.0 i SnapRAID 14.5 oraz umożliwiła zamontowanie testowej puli mergerfs. Tester utworzył plik za pośrednictwem ścieżki puli i zweryfikował, że pojawił się on w bazowej gałęzi przed prawidłowym odmontowaniem.
Test ten nie obejmował pełnego testu parzystości i odzyskiwania SnapRAID. Tester wyłączył również domyślne liczniki czasu i usługi przed rozpoczęciem konfiguracji, aby nie mogły przypadkowo działać na rzeczywistych dyskach.
Wykryto i skorygowano dwa wyścigi przy uruchamianiu systemu
Po ponownym uruchomieniu systemu jeden z użytkowników zauważył, że pula czasami się nie uruchamiała, choć późniejsze ręczne uruchomienie kończyło się powodzeniem. Autor rozszerzenia zidentyfikował dwa niezależne wyścigi. Po pierwsze, pierwotny warunek kontrolny wykrywał starszy plik binarny mergerfs dostarczany przez system bazowy i uruchamiał pulę, zanim nowszy plik binarny z rozszerzenia został scalony. Zmieniony warunek sprawdzał obecność SnapRAID, który był dostarczany wyłącznie przez rozszerzenie.
Po drugie, mergerfs mógł zwrócić powodzenie, zanim fizyczne dyski gałęzi zostały zamontowane, tworząc pustą pulę, która ukrywała pamięć masową pojawiającą się później. Prosta pętla Restart=on-failure nie mogła wykryć tego stanu zakończonego powodzeniem, ale pustego. Projekt dodał jawne kontrole, które czekają na zamontowanie każdej gałęzi i odmawiają utworzenia puli, jeśli którejś gałęzi brakuje.
Autor poinformował o weryfikacji po zimnym ponownym uruchomieniu na ZimaOS 1.6.1 po wprowadzeniu tych zmian. Użytkownik z czterodyskową obudową TerraMaster również zgłosił, że pula ostatecznie się pojawiła, gdy montowanie dysków zajęło niemal minutę.
Bezpieczeństwo SnapRAID nadal wymaga kontroli operatora
Rozszerzenie zawierało próg usuwania, który miał zatrzymać synchronizację po wykryciu nieoczekiwanie dużej liczby usunięć. Późniejszy użytkownik zapytał, jak obejść ten próg po celowym usunięciu tysięcy plików. Wątek nie udzielił ostatecznej odpowiedzi na to pytanie operacyjne.
Każdy, kto ocenia ten projekt, powinien sprawdzić ścieżki gałęzi, ścieżki plików parzystości, liczniki czasu, progi usuwania oraz lokalizację danych aplikacji przed włączeniem zadań automatycznych. Pomyślna kontrola pliku binarnego lub zamontowanie mergerfs nie jest dowodem przetestowania odzyskiwania parzystości dla danych produkcyjnych.
Granice wsparcia
Jest to zaawansowana integracja stworzona przez społeczność, a nie obsługiwana przez IceWhale funkcja pamięci masowej ZimaOS. Docker, pełna maszyna wirtualna z Linuksem, pliki binarne skompilowane statycznie oraz sysext mają różne charakterystyki uprawnień i trwałości. Najważniejszym rezultatem wątku jest przetestowana metoda z użyciem rozszerzenia, ale mimo to należy ją ocenić na testowej pamięci masowej przed wprowadzeniem jakichkolwiek rzeczywistych danych.
FAQ
Czy mergerfs jest już dołączony do ZimaOS?
Jeden z uczestników potwierdził obecność pliku binarnego mergerfs na swoim ZimaCube. Później w wątku ustalono, że ta kopia systemowa była starszą wersją, więc jej obecność nie gwarantuje zgodności z nowoczesną konfiguracją.
Czy odzyskiwanie danych przez SnapRAID zostało w pełni przetestowane?
Nie. Kontrolowany test zweryfikował instalację i testową pulę mergerfs, ale wyraźnie nie obejmował pełnego testu parzystości i przywracania SnapRAID.
Dlaczego oczekiwanie na awarię usługi nie wystarczyło?
Jeden z wyścigów mógł utworzyć pustą pulę przy kodzie wyjścia oznaczającym powodzenie. Ponieważ nie był to błąd, sama reguła restartowania po awarii mogła go nie wykryć.
