Ten wątek opisuje zaawansowaną konfigurację pamięci masowej, która działała poprawnie od strony technicznej, ale nie była w pełni rozpoznawana przez interfejs pamięci masowej ZimaOS. Użytkownik ręcznie utworzył natywny mirror Btrfs i poinformował, że konfiguracja przetrwała ponowne uruchomienia oraz nadal obsługiwała Dockera i inne usługi.
Najważniejsze ostrzeżenie jest takie, że ZimaOS nadal wyświetlał drugi dysk członkowski jako możliwy do skonfigurowania. Stwarza to realne ryzyko: interfejs, który nie rozumie ręcznie zarządzanej macierzy, może proponować działania, które są dla niej niebezpieczne.
Dlaczego natywny Btrfs RAID1 jest inny
W przypadku natywnego replikowanego profilu Btrfs system plików wie, że istnieje wiele kopii danych. Oficjalna dokumentacja dotycząca działania scrub w Btrfs wyjaśnia, że scrub może weryfikować sumy kontrolne, a w replikowanych profilach, takich jak RAID1, naprawiać uszkodzone dane, kopiując je ze sprawdzonej, poprawnej repliki.
W dyskusji społecznościowej zestawiono to z układem, w którym Btrfs widzi pojedyncze logiczne urządzenie blokowe udostępniane przez inną warstwę RAID. W takim przypadku Btrfs nie ma takiej samej widoczności poszczególnych urządzeń, aby podejmować decyzje dotyczące samonaprawy.
Co zadziałało w teście społeczności
- Ręcznie utworzony mirror Btrfs zamontował się poprawnie.
- Macierz przetrwała ponowne uruchomienie.
- Docker i inne usługi nadal działały.
Te obserwacje są użytecznym dowodem na to, że warstwa Linuksa może współpracować z tym systemem plików. Nie dowodzą jednak, że ZimaOS oficjalnie zarządza taką konfiguracją kompleksowo.
Głównym zagrożeniem jest interfejs pamięci masowej
Użytkownik poinformował, że ZimaOS nadal przedstawiał drugi dysk jako dysk, który można zainicjalizować. Jeśli zarządzasz systemem plików poza menedżerem pamięci masowej, unikaj korzystania z działań w interfejsie, które zakładają, że te dyski członkowskie są wolne lub niezarządzane.
Nie testuj destrukcyjnych działań związanych z pamięcią masową na danych, których nie możesz odtworzyć. Ręczne zarządzanie Btrfs RAID należy traktować jako zaawansowany, nieobsługiwany sposób pracy, chyba że aktualna dokumentacja ZimaOS wyraźnie stanowi inaczej.
Aktualny kontekst bezpieczeństwa pamięci masowej
Przed rozpoczęciem eksperymentów z macierzą zawierającą rzeczywiste dane bezpieczniejszym punktem odniesienia jest procedura odzyskiwania RAID 1, która pomaga zachować istniejące metadane RAID i uniknąć destrukcyjnego tworzenia macierzy od nowa. Strona Zmiany w ZimaOS 1.5 zapewnia kontekst wersji dotyczący zmian w zarządzaniu pamięcią masową w ZimaOS, natomiast omówienie chmury osobistej ZimaOS wyjaśnia, jak pule pamięci masowej wpisują się w szerszy model zarządzania danymi w ZimaOS.
Oficjalna dokumentacja profili RAID Btrfs wymienia RAID1 jako replikowany profil Btrfs z dwiema kopiami, a dokumentacja dotycząca działania scrub w Btrfs wyjaśnia, że scrub może naprawiać uszkodzone dane w replikowanych profilach, kopiując je ze sprawdzonej, poprawnej repliki. Te możliwości systemu plików wynikające z projektu upstream wyjaśniają, dlaczego autor oryginalnego wpisu preferował natywny Btrfs RAID1, ale nie oznaczają, że ZimaOS obecnie zarządza każdą ręcznie utworzoną topologią Btrfs za pomocą swojego interfejsu.
Podsumowanie
Natywny mirror Btrfs RAID1 może zapewniać replikację uwzględniającą sumy kontrolne, której oczekiwał autor oryginalnego wpisu, a test społeczności zakończył się powodzeniem. Ograniczeniem było zarządzanie: ZimaOS nie rozumiał w pełni drugiego dysku członkowskiego. System plików może działać poprawnie od strony technicznej, podczas gdy interfejs pamięci masowej pozostaje niebezpiecznym elementem.
