Ostatecznie to źródło doprowadziło do potwierdzenia przyczyny problemu przez IceWhale. Po aktualizacji do ZimaOS 1.5.3 sama macierz RAID NVMe została złożona i zamontowana, ale zimaos-local-storage natychmiast ją odmontował, ponieważ baza danych RAID zawierała fs_type = 'BTRFS' wielkimi literami zamiast małymi literami oczekiwanymi przez menedżera pamięci masowej.
Dina z IceWhale przekazała ukierunkowane polecenie aktualizacji SQLite. Autor oryginalnego wpisu uruchomił je i wyraźnie potwierdził, że później RAID montował się normalnie. Następnie ZimaOS 1.5.4 wymienił problem automatycznego montowania macierzy RAID BTRFS zapisanej wielkimi literami jako oficjalnie naprawiony. Obecni użytkownicy powinni zatem traktować polecenie SQL jako historyczną instrukcję odzyskiwania dotyczącą dokładnie tego błędu, a nie jako ogólne polecenie naprawy RAID.
Macierz RAID była sprawna, zanim menedżer pamięci masowej ją odmontował
Dziennik pokazywał automatyczne wykrycie RAID przez jądro, a systemd montował /media/RAID-Storage-2, a następnie zimaos-local-storage odmontowując go kilka sekund później.
Źródłowy rekord w bazie danych również wskazywał RAID jako status ok. Dzięki temu mniej prawdopodobne było, że przyczyną problemu był uszkodzony członek macierzy lub zniszczony system plików Btrfs.
Ręczny wpis w fstab działał tylko jako tymczasowe obejście
Użytkownik ręcznie zamontował RAID i dodał /etc/fstab wpis, ale zarządzanie pamięcią masową w ZimaOS nie traktowało go jako konfiguracji nadrzędnej. Po ponownym uruchomieniu usługa local-storage nadal wymuszała użycie swojego wewnętrznego stanu i bazy danych.
Dlatego pamięcią masową zarządzaną przez urządzenie należy zwykle zarządzać za pośrednictwem warstwy pamięci masowej ZimaOS, zamiast utrzymywać równoległe ręczne montowanie.
Społeczność prawidłowo wskazała zimaos-local-storage jako warstwę odpowiedzialną
Zanim IceWhale opublikowało przyczynę problemu, gelbuilding zauważył kluczową sekwencję: montowanie kończy się powodzeniem, a następnie zimaos-local-storage odmontowuje go. Słusznie zalecił przesłanie logów do IceWhale zamiast wielokrotnego modyfikowania metadanych RAID.
Jego przypuszczenie dotyczące bardziej rygorystycznej walidacji nie było ostateczną diagnozą; późniejsza oficjalna diagnoza była znacznie bardziej szczegółowa.
IceWhale znalazło błąd wielkości liter w fs_type
Dina napisała, że baza danych fs_type wartość była zapisana wielkimi literami, co powodowało niepowodzenie montowania. IceWhale podało:
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"Użytkownik odpowiedział później: „To rzeczywiście rozwiązało problem”.
BTRFS małymi literami btrfs.ZimaOS 1.5.4 oficjalnie naprawił ten sam błąd automatycznego montowania
Informacje o wydaniu 1.5.4 wyraźnie wymieniają poprawkę błędu automatycznego montowania, gdy rekordy bazy danych RAID przechowywały BTRFS wielkimi literami.
Zobacz oficjalną poprawkę montowania RAID w ZimaOS 1.5.4.
Użytkownik wersji 1.5.4 zgłosił później, że RAID nadal nie jest zamontowany
Inny uczestnik powiedział, że na jego systemie w wersji 1.5.4 nadal występował problem z montowaniem. Dina poprosiła o świeżą diagnostykę dysku i opis objawów, zamiast zakładać, że nadal chodzi o błąd uppercase-fs_type.
To właściwa granica: podobne objawy mogą mieć różne przyczyny.
Nie uruchamiaj starego zapytania SQL na aktualnym RAID bez potwierdzających dowodów
Aktualna wersja ZimaOS to 1.7.1. Przed ingerencją w local-storage.db, sprawdź, czy:
- tablica faktycznie się składa;
- dziennik pokazuje, że usługa local-storage ją odmontowuje;
- baza danych rzeczywiście zawiera historyczną wartość zapisaną wielkimi literami;
- masz aktualną kopię zapasową i raport diagnostyczny.
Jeśli te warunki nie są spełnione, edycja bazy danych może utrudnić odzyskanie danych z innego problemu z pamięcią masową.
Oficjalną poprawkę znaleziono dzięki dziennikom dostarczonym przez użytkownika
IceWhale poprosiło o /ZimaOS-HD/.log/casaos/local-storage.log po zidentyfikowaniu przez społeczność warstwy menedżera pamięci masowej. Ten dziennik pozwolił zespołowi przejść od ogólnej teorii do dokładnego błędu dotyczącego wielkości liter.
W przypadku bieżącej awarii montowania zachowaj ten sam zestaw dowodów: stan składania RAID, wpisy dziennika, stan pamięci masowej ZimaOS oraz diagnostykę pamięci lokalnej przed modyfikacją metadanych.
Wykonaj kopię zapasową wewnętrznych metadanych przed ręczną edycją bazy danych
Źródłowe zapytanie SQL było jednolinijkową poprawką dostarczoną przez IceWhale dla znanego błędu w wersji 1.5.3. Jeśli kiedykolwiek ponownie będzie potrzebna edycja bazy danych przeprowadzana na polecenie pracownika, najpierw wykonaj kopię zapasową bazy danych/stanu, a następnie zastosuj wyłącznie dokładny warunek, którego dotyczy poprawka.
Szeroko zakrojone aktualizacje SQL dotyczące rekordów RAID mogą rozłączyć widok menedżera pamięci masowej z rzeczywistą tablicą i zamienić możliwy do naprawienia błąd montowania w problem odzyskiwania metadanych.
Ponowna instalacja nie jest pierwszą reakcją na zdrowy, lecz niezmontowany RAID
Ponieważ sama tablica została złożona, a dane były nienaruszone, ponowna instalacja lub odtworzenie RAID byłoby niepotrzebnie destrukcyjne. Gdy zdrowa tablica jest odrzucana z powodu metadanych zarządzania, przed ingerencją w geometrię tablicy należy naprawić warstwę zarządzania lub skorzystać ze wsparcia producenta.
FAQ dotyczące montowania RAID
Czy sam RAID został zniszczony w źródle?
Nie. Tablica została złożona i zamontowana, zanim zarządzanie pamięcią masową ZimaOS ją odmontowało.
Jaka była potwierdzona główna przyczyna?
Baza danych RAID przechowywała fs_type wielkimi literami BTRFS zamiast małymi literami btrfs.
Czy IceWhale naprawiło to w którymś wydaniu?
Tak. W ZimaOS 1.5.4 wyraźnie wymieniono błąd automatycznego montowania BTRFS zapisanego wielkimi literami jako naprawiony.
