Zbudowałem programowy RAID, zrestartowałem i pamięci masowej nie ma: macierz nie jest składana przy starcie

Połączyłeś dyski, macierz wstała, pamięć masowa się pojawiła, zapisałeś na niej dane. Wszystko działało.

Potem zrestartowałeś maszynę i pamięci masowej nie ma.

Dyski są zdrowe. Dane nadal tam są. Brakuje czegoś innego.

Macierz nie leży na dyskach, tylko w instrukcji składania

Przedstawienie kilku dysków jako jednej pamięci masowej nie jest własnością siedzącą na dyskach. Przy każdym starcie system musi te dyski odnaleźć i złożyć je z powrotem.

Jest zapis mówiący mu, jak to zrobić. Bez tego zapisu macierz może nie zostać złożona. Nawet jeśli zostanie, może wstać pod inną nazwą, co sprowadza się do tego samego: twoja pamięć masowa wskazuje na starą nazwę, a tam nic nie ma.

Problem nie brzmi więc, że dane zostały utracone, tylko że droga do danych nie została przy starcie zbudowana. Brzmi to mniej strasznie, ale w chwili paniki obie rzeczy czuje się identycznie.

Własne stanowisko Proxmoksa

To zasługuje na uczciwe powiedzenie: wbudowaną i wspieraną drogą w Proxmoksie jest ZFS. Poproś podczas instalacji o lustrzane odbicie dysków, a dostaniesz właśnie to.

Klasyczny RAID programowy działa, ale nie jest tą drogą, którą przygotowuje ci instalator. Znaczy to, że gdy go wybierasz, upewnienie się, że kroki składania przy starcie zostały wykonane poprawnie, spada na ciebie.

Wciąż istnieją przypadki, w których ma to sens: masz już macierz i ją przenosisz, twój układ kontrolerów nie jest tym, czego oczekuje ZFS, albo pamięć maszyny jest dla ZFS ciasna. To są prawdziwe powody. Wybieranie tej drogi bez żadnego z nich to robienie roboty samemu sobie z przyszłości.

Reguła: macierz, która nie widziała restartu, nie liczy się jako macierz

To najbardziej praktyczne zdanie tego wpisu.

Po zbudowaniu macierzy zrestartuj raz celowo, póki nic od niej nie zależy. Czy pamięć masowa wraca, czy wraca pod tą samą nazwą, czy zawartość jest widoczna.

To samo napisaliśmy we wpisie o alarmach w tej bazie wiedzy: nieprzetestowany alarm nie jest mechanizmem, tylko nadzieją. To samo dotyczy macierzy. Macierz, która nie przeżyła restartu, jest macierzą, o której wierzysz, że działa.

Pułapka zmiany nazwy

Druga częsta pułapka: macierz zostaje złożona, ale pod inną nazwą niż poprzednio.

Twoja definicja pamięci masowej wskazuje na starą nazwę, więc pamięć masowa znowu jest niewidoczna. Tym razem macierz stoi, tylko nikt na nią nie patrzy.

Poprawka polega na podpięciu pamięci masowej po tożsamości, a nie po nazwie. Nazwy mogą się zmieniać, tożsamości nie.

Co robi Atlas

Gdy Atlas buduje macierz, zapisuje też wpis startowy i pokazuje na ekranie takie ostrzeżenie: jeśli ten krok się nie uda, macierz może nie zostać złożona przy starcie, a pamięć masowa stanie się niewidoczna.

Ostrzeżenie było prawdziwe. Ale przez pewien czas podkopywało samo siebie.

Do wytworzenia zapisu wywoływane było własne narzędzie systemu. Zmierzono to i wyszło, co następuje: gdy nie ma żadnej macierzy, to narzędzie kończy się kodem zero i nic nie wypisuje. Innymi słowy mówi sukces i nie podaje ci niczego.

Wynik: nic nie zostało zapisane, a krok został odnotowany jako udany. Użytkownikowi przydarzało się dokładnie to, co ostrzeżenie przed chwilą opisało, podczas gdy ekran pokazywał, że wszystko jest w porządku.

Poprawka miała dwie części. Oczekiwany format ustalono przez pomiar, a nie przez zgadywanie, i jeśli wyjście nie pasuje do tego formatu, krok liczy się jako nieudany. Puste wyjście też jest porażką. A żeby nie zapisać tej samej macierzy dwa razy, sprawdzane są zarówno ścieżka urządzenia, jak i tożsamość.

Ogólna lekcja

Zdanie, które ma tu znaczenie, brzmi tak: polecenie się powiodło i praca została wykonana to nie to samo.

Kod wyjścia mówi ci, czy narzędzie się uruchomiło. Nie mówi, czy skutek nastąpił. Jeśli całym celem kroku jest wywołanie skutku, to sprawdzać należy nie stan narzędzia, tylko sam skutek.

W tej bazie wiedzy są jeszcze dwa wpisy z tej samej rodziny. We wpisie o osieroconych dyskach oddzieliliśmy pustą odpowiedź od braku odpowiedzi. We wpisie o nazwie serwera było niebezpieczeństwo wstawiania wiarygodnie wyglądającej wartości domyślnej w miejsce nieznanego. To jest trzecie: wstawianie kodu wyjścia w miejsce skutku, którego nigdy nie ustalono.

Wszystkie trzy są twarzami tej samej usterki: program twierdzi coś, czego nie sprawdził.