Rozumiem, że dyski twarde i dyski SSD implementują podstawowe korekcje błędów wewnątrz dysku, a większość konfiguracji RAID, np. Mdadm, będzie zależeć od tego, aby zdecydować, kiedy dysk nie naprawi błędu i musi zostać przełączony w tryb offline. Zależy to jednak od tego, czy pamięć jest w 100% dokładna w diagnozie błędów. Tak nie jest, a wspólna konfiguracja, taka jak dwudyskowe lustro RAID-1, będzie podatna na atak: załóżmy, że niektóre bity na jednym dysku są cicho uszkodzone, a dysk nie zgłasza błędu odczytu. Dlatego systemy plików, takie jak btrfs i ZFS, implementują własne sumy kontrolne, aby nie ufać błędnym oprogramowaniom napędowym, uszkodzonym kablom SATA i tak dalej.
Podobnie pamięć RAM może mieć problemy z niezawodnością, dlatego mamy pamięć ECC RAM, aby rozwiązać ten problem.
Moje pytanie brzmi : jaki jest kanoniczny sposób ochrony pliku wymiany Linuksa przed cichym uszkodzeniem / zgnilizną bitów, która nie została złapana przez oprogramowanie napędu w konfiguracji z dwoma dyskami (tj. Przy użyciu sterowników jądra głównego)? Wydaje mi się, że konfiguracja pozbawiona tutaj kompleksowej ochrony (taka jak ta zapewniona przez btrfs) nieco neguje spokój ducha przyniesiony przez RAM ECC. Nie mogę jednak wymyślić dobrego sposobu:
- btrfs w ogóle nie obsługuje plików wymiany. Możesz skonfigurować urządzenie pętlowe z pliku btrfs i dokonać na nim wymiany. Ale to ma problemy:
- Losowe zapisy nie działają dobrze: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
- Sugestia wyłączenia kopiowania przy zapisie spowoduje również wyłączenie sumowania kontrolnego - tym samym pokonując cały punkt tego ćwiczenia. Zakładają, że plik danych ma własne zabezpieczenia wewnętrzne.
- ZFS w Linuksie pozwala na używanie ZVOL-a jako wymiany, co, jak sądzę, mogłoby działać: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - jednak z moich odczytów, ZFS zwykle wymaga pamięci i sprawienia, by działała w trybie wymiany -Tylko aplikacja brzmi jak praca nad rozgryzaniem. Myślę, że to nie jest mój pierwszy wybór. Dlaczego musiałbyś użyć jakiegoś nie-drzewa modułu jądra tylko po to, aby mieć niezawodną zamianę, która jest poza mną - na pewno istnieje sposób, aby to osiągnąć za pomocą większości współczesnych dystrybucji / jąder Linuksa w dzisiejszych czasach?
- Na liście mailingowej jądra Linuksa znajdował się wątek z łatami umożliwiającymi sumy kontrolne w samym menedżerze pamięci, właśnie z powodów, które omawiam w tym pytaniu: http://thread.gmane.org/gmane.linux.kernel/989246 - niestety, o ile mogę stwierdzić, łatka umarła i nigdy nie dotarła do góry z nieznanych mi powodów. Szkoda, że brzmiało to jak fajna funkcja. Z drugiej strony, jeśli umieścisz swap na RAID-1 - jeśli uszkodzenie nie jest w stanie naprawić sumy kontrolnej, chciałbyś, aby menedżer pamięci spróbował odczytać z drugiego dysku przed panikowaniem lub czymkolwiek innym, co jest prawdopodobnie poza zakresem tego, co powinien zrobić menedżer pamięci.
W podsumowaniu:
- Pamięć RAM ma ECC do korygowania błędów
- Pliki w pamięci trwałej mają btrfs do naprawy błędów
- Zamień ma ??? <--- to moje pytanie
źródło
Odpowiedzi:
Ufamy integralności danych pobranych z wymiany, ponieważ sprzęt pamięci ma sumy kontrolne, CRC i tym podobne.
W jednym z powyższych komentarzy mówisz:
„To” oznacza tutaj sumy kontrolne dysku.
To prawda, ale SATA używa 32-bitowych CRC do poleceń i danych. Dzięki temu masz 1 do 4 miliardów szans na niewykrywalne uszkodzenie danych między dyskiem a kontrolerem SATA. Oznacza to, że źródło ciągłego błędu może wprowadzać błąd tak często, jak co każde 125 MiB przesyłanych, ale rzadkie, losowe źródło błędów, takie jak promienie kosmiczne, powodowałoby niewykrywalne błędy w znikomym tempie.
Zrozum również, że jeśli masz źródło, które powoduje niewykryty błąd z częstotliwością prawie jednego na 125 przesłanych MiB, wydajność będzie straszna z powodu dużej liczby wykrytych błędów wymagających ponownego przesłania. Monitorowanie i rejestrowanie prawdopodobnie ostrzegą o problemie w odpowiednim czasie, aby uniknąć niewykrywalnego uszkodzenia.
Jeśli chodzi o sumy kontrolne nośnika pamięci, każdy dysk SATA (a przed nim PATA) używa pewnego rodzaju sum kontrolnych dla każdego sektora. Jedną z charakterystycznych cech dysków „korporacyjnych” są większe sektory chronione przez dodatkowe funkcje integralności danych , co znacznie zmniejsza ryzyko niewykrycia błędu.
Bez takich środków pula wolnych sektorów nie miałaby sensu na każdym dysku twardym: sam dysk nie mógł wykryć uszkodzonego sektora, więc nigdy nie mógł wymienić nowych sektorów.
W innym komentarzu pytasz:
Ogólnie rzecz biorąc, nie prosimy o zamianę przechowywania danych w długim okresie. Ograniczeniem przestrzeni wymiany na wymianę jest czas pracy systemu , a większość danych w swapie nie trwa tak długo, ponieważ większość danych przechodzących przez system pamięci wirtualnej systemu należy do procesów o znacznie krótszym czasie życia.
Co więcej, czas przestojów ogólnie skrócił się z biegiem lat, co przy zwiększonej częstotliwości jądra i
libcaktualizacji, wirtualizacji, architekturze chmury itp.Co więcej, większość danych w swap jest z natury nieużywana w dobrze zarządzanym systemie, który nie kończy się w głównej pamięci RAM. W takim systemie jedyne, co kończy się zamianą, to strony , z których program nie korzysta często, jeśli w ogóle. Jest to częstsze, niż można się domyślać. Większość bibliotek dynamicznych, które łączą twoje programy, zawiera procedury, których program nie używa, ale musiały zostać załadowane do pamięci RAM przez dynamiczny linker . Gdy system operacyjny widzi, że nie używasz cały tekst programu w bibliotece, to zamienia go, robiąc miejsce dla kodu i danych, które programy są używane. Gdyby takie zamienione strony pamięci były uszkodzone, kto by to wiedział?
Porównaj to z ZFS, w którym spodziewamy się, że dane będą przechowywane trwale i trwale, dzięki czemu będą trwały nie tylko poza bieżącym czasem pracy systemu, ale także poza żywotnością poszczególnych urządzeń pamięci masowej, które składają się na system pamięci masowej. ZFS i tym podobne rozwiązują problem ze skalą czasową o około dwa rzędy wielkości dłuższą niż problem rozwiązany przez zamianę. Dlatego mamy znacznie wyższe wymagania dotyczące wykrywania uszkodzeń w ZFS niż w przypadku wymiany Linux.
ZFS i tym podobne różnią się od wymiany w inny kluczowy sposób: nie wymieniamy razem systemów plików RAID. Gdy na jednym komputerze używanych jest wiele urządzeń wymiany , jest to schemat JBOD , a nie RAID-0 lub wyższy. (np. schemat łańcuchowych plików wymiany systemu macOS , Linux
swaponitp.) Ponieważ urządzenia wymiany są niezależne, a nie współzależne jak w przypadku RAID, nie potrzebujemy obszernego sprawdzania, ponieważ wymiana urządzenia wymiany nie wymaga patrzenia na inne wzajemnie zależne urządzenia wymiany dane, które powinny trafić na urządzenie zastępcze. Z punktu widzenia ZFS nie przeprowadzamy resilveru wymiany urządzeń z nadmiarowych kopii na innych urządzeniach pamięci masowej.Wszystko to oznacza, że musisz używać niezawodnego urządzenia wymiany. Kiedyś użyłem zewnętrznej obudowy USB HDD o wartości 20 USD, aby uratować niewydolną pulę ZFS, tylko po to, aby odkryć, że sama obudowa była niewiarygodna, wprowadzając własne błędy do procesu. Uratowało mnie tutaj silne sumowanie ZFS. Nie można uciec od tak nonszalanckiego traktowania nośników danych za pomocą pliku wymiany. Jeśli urządzenie wymiany umiera, a zatem zbliża się do tego najgorszego przypadku, w którym może wprowadzić niewykrywalny błąd co 125 przesyłanych MiB, wystarczy go jak najszybciej wymienić.
Ogólne poczucie paranoi w tym pytaniu przechodzi do przykładu problemu bizantyjskich generałów . Przeczytaj to, zastanów się nad datą 1982 r. W artykule naukowym opisującym problem w świecie informatyki, a następnie zdecyduj, czy w 2019 r. Będziesz miał nowe przemyślenia, które możesz dodać do tego problemu. A jeśli nie, być może użyjesz technologii zaprojektowanej przez trzy dekady absolwentów CS, którzy wszyscy wiedzą o problemie bizantyjskich generałów.
To jest dobrze zdeptane podłoże. Prawdopodobnie nie możesz znaleźć pomysłu, sprzeciwu lub rozwiązania, które nie zostało jeszcze omówione na śmierć w czasopismach informatycznych.
SATA z pewnością nie jest całkowicie niezawodna, ale jeśli nie dołączysz do środowisk akademickich lub jednego z zespołów programistycznych jądra, nie będziesz w stanie wnieść istotnego postępu w tej dziedzinie. Te problemy są już dobrze przygotowane, jak już zauważyłeś: ZFS, btrfs, ReFS ... Jako użytkownik systemu operacyjnego musisz po prostu zaufać, że twórcy systemu operacyjnego zajmują się tymi problemami, ponieważ oni również wiedzą o bizantyjskich generałach.
To nie jest aktualnie praktyczny umieścić plik wymiany na szczycie ZFS lub btrfs, ale jeśli powyższe nie cię uspokoić, można przynajmniej umieścić go na szczycie XFS lub ext4. To byłoby lepsze niż użycie dedykowanej partycji wymiany.
źródło
integralność dm
Zobacz: Documentation / device-mapper / dm-integrity.txt
dm-integritybyłby normalnie używany w trybie dziennikowania. W przypadku wymiany możesz zrobić to bez dziennikowania. Może to znacznie obniżyć narzut wydajności. Nie jestem pewien, czy trzeba ponownie sformatować partycję wymiany integralności przy każdym rozruchu, aby uniknąć przechwytywania błędów po nieczystym zamknięciu.W pierwszym ogłoszeniu
dm-integrityautor preferuje „ochronę integralności danych na wyższym poziomie”. W przypadku wymiany otworzyłoby to możliwość przechowywania sum kontrolnych w pamięci RAM. Jednak ta opcja wymagałaby nie trywialnych modyfikacji obecnego kodu wymiany i zwiększyła wykorzystanie pamięci. (Obecne ścieżki kodu zamieniają się efektywnie przy użyciu zakresów, a nie poszczególnych stron / sektorów).DIF / DIX?
Obsługa DIX została dodana przez Oracle w Linux 2.6.27 (2008).
Czy korzystanie z DIX zapewnia kompleksową integralność?
Możesz skonsultować się ze sprzedawcą. Nie wiem, jak można powiedzieć, czy kłamią.
DIX jest wymagany do ochrony danych w locie między systemem operacyjnym (systemem operacyjnym) a kartą HBA .
Sam DIF zwiększa ochronę danych w locie między kartą HBA a urządzeniem pamięci masowej . (Zobacz także: prezentacja z niektórymi danymi liczbowymi na temat różnicy w poziomach błędów ).
Właśnie dlatego, że suma kontrolna w zakresie straży jest znormalizowany, to jest technicznie możliwe do wykonania polecenia Dix bez podania żadnej ochrony danych w spoczynku. Wystarczy, aby HBA (lub urządzenie pamięci masowej) ponownie wygenerowało sumę kontrolną w czasie odczytu. Perspektywa ta była dość jasna w oryginalnym projekcie DIX.
Jeden z ich wczesnych postów na temat DIX wspomina o możliwości używania DIX między systemem operacyjnym a kartą HBA, nawet jeśli dysk nie obsługuje DIF.
Całkowita kłamliwość jest stosunkowo mało prawdopodobna w kontekstach „korporacyjnych”, w których obecnie stosuje się DIX; ludzie to zauważą. Ponadto DIF został oparty na istniejącym sprzęcie, który można sformatować za pomocą sektorów 520-bajtowych. Protokół korzystania z DIF rzekomo wymaga, aby najpierw sformatować dysk, patrz np.
sg_formatPolecenie.Bardziej prawdopodobne jest wdrożenie, które nie jest zgodne z prawdziwą zasadą end-to-end . Aby podać jeden przykład, wymieniono dostawcę, który obsługuje słabszą opcję sumy kontrolnej dla DIX w celu zapisania cykli procesora, która jest następnie zastępowana przez silniejszą sumę kontrolną na dole stosu. Jest to przydatne, ale nie jest kompletną kompleksową ochroną.
Alternatywnie system operacyjny może wygenerować własne sumy kontrolne i przechowywać je w obszarze znaczników aplikacji. Jednak w obecnej wersji Linuksa (v4.20) nie ma takiej obsługi . Komentarz napisany w 2014 r. Sugeruje, że może to być spowodowane tym, że „bardzo niewiele urządzeń pamięci masowej faktycznie zezwala na używanie przestrzeni znaczników aplikacji”. (Nie jestem pewien, czy odnosi się to do samego urządzenia pamięci, karty HBA, czy obu).
Jakie rodzaje urządzeń DIX są dostępne, które działają w systemie Linux?
Wikipedia mówi mi, że DIF jest znormalizowany w NVMe 1.2.1. W przypadku kart SCSI HBA wydaje się to nieco trudne, jeśli nie mamy standardu, na który można wskazać. W tej chwili może być najdokładniej mówić o obsłudze „Linux DIX” :-). Dostępne są urządzenia:
Cały sprzęt wymieniony w informacjach o wersji RHEL 7.5 to Fibre Channel.
Nie znam tego rynku. Wygląda na to, że DIX może w przyszłości stać się bardziej dostępny na serwerach. Nie znam żadnego powodu, dla którego stałby się dostępny dla konsumenckich dysków SATA - o ile wiem, nie ma nawet de facto standardu dla formatu poleceń. Będę zainteresowany, aby dowiedzieć się, czy będzie on dostępny szerzej na NVMe.
źródło
W Linuksie zamiana nadal nie jest chroniona (ale patrz UPD).
Cóż, oczywiście istnieje ZFS w Linuksie, który może być magazynem wymiany, ale w niektórych okolicznościach nadal występuje blokada - w ten sposób skutecznie odwołując tę opcję.
Btrfs nadal nie obsługuje plików wymiany . Wspominają o możliwym użyciu sprzężenia zwrotnego, chociaż zauważono, że ma słabą wydajność. Pewne wskazanie jest niejasne, że Linux 5 może to mieć w końcu (?)…
Łaty do ochrony samego konwencjonalnego swapu za pomocą sum kontrolnych nie trafiły do głównego nurtu.
Tak więc wszystko w sumie: nie. Linux wciąż ma lukę.
UPD. : Jak wskazuje @ sourcejedi , istnieje takie narzędzie jak integralność dm. Jądro Linuksa od wersji 4.12 ma cel mapowania urządzeń, który można wykorzystać do dostarczania sum kontrolnych do dowolnych ogólnych urządzeń blokowych, a te, które są przeznaczone do wymiany, nie są wyjątkiem. Oprzyrządowanie nie jest szeroko włączone do głównych dystrybucji i większość z nich nie ma żadnego wsparcia w podsystemie udev, ale ostatecznie to powinno się zmienić. Po sparowaniu z dostawcą redundancji, powiedzmy, umieszczonym na szczycie MD znanej również jako Linux Software RAID, powinno być możliwe nie tylko wykrycie zgnilizny bitów, ale także przekierowanie żądania We / Wy do zdrowych danych, ponieważ integralność dm wskazuje, że istnieje problem i MD powinien sobie z tym poradzić.
źródło
Nie sądzę, że istnieje sposób „kanoniczny”, więc moja osobista opinia jest następująca.
Po monitorowaniu postępu btrfs z punktu widzenia potencjalnego użytkownika, muszę powiedzieć, że wciąż jest dla mnie niejasny. Istnieją funkcje, które są dojrzałe i gotowe do użytku produkcyjnego, i są funkcje, które wydają się niedojrzałe i niebezpieczne w użyciu.
Osobiście nie mam czasu, aby zdecydować, której funkcji użyć, a która nie. Pozwól mi poświęcić czas, który potrzebuję, aby dowiedzieć się, jak wyłączyć lub włączyć te funkcje.
W przeciwieństwie do tego, ZFS jest solidny i dojrzały (IMHO). Tak więc, aby odpowiedzieć na twoje pytanie, użyłbym ZFS (nawiasem mówiąc, nie zużywa dużo pamięci - patrz poniżej).
Ale dla ciebie btrfs może być właściwym wyborem, ponieważ już go używasz (jeśli dobrze zrozumiałem), a jeden z powyższych komentarzy pokazuje, jak go używać do wymiany.
Przez przypadek umieściłem kilka serwerów Linux na ZFS w ciągu ostatnich dni, za każdym razem włączając system plików root i swap. Zanim to zrobiłem, przeprowadziłem bardzo dokładne badania, co zajęło mi kilka dni. Krótkie streszczenie tego, czego się nauczyłem:
Zużycie pamięci ZFS
Występuje powszechne nieporozumienie dotyczące zużycia pamięci ZFS. ZFS ogólnie nie zużywa dużo pamięci; w rzeczywistości działa z TB pamięci masowej na komputerach z 2 GB pamięci RAM. Tylko jeśli używasz deduplikacji (domyślnie wyłączona), to potrzebuje dużo pamięci RAM.
Wykrywanie / korekcja błędów sprzętowych
To, czy SATA, PATA, RAID lub inne mechanizmy wykrywania / korekcji błędów są wystarczające dla integralności danych, jest tematem, który powoduje niekończące się dyskusje, a nawet wojny płomieni we wszystkich miejscach w sieci. Teoretycznie sprzętowe urządzenie magazynujące powinno zgłaszać (i być może poprawiać) każdy napotkany błąd, a sprzęt do transmisji danych na wszystkich poziomach (mikroukład, pamięć itp.) Powinien również to robić.
Cóż, nie we wszystkich przypadkach lub zaskakująco reagują na błędy. Jako przykład weźmy typową konfigurację RAID5. Zwykle, jeśli jeden dysk ma problem, zgłosi go do macierzy RAID, która z kolei konstruuje dane do odczytu z innych dysków i przekazuje je dalej, ale także zapisuje je z powrotem na wadliwym dysku (który z kolei prawdopodobnie ponownie mapuje sektor przed zapisaniem danych); jeśli ten sam dysk zgłasza zbyt wiele błędów, RAID przełącza go w tryb offline i informuje administratora (jeśli jest odpowiednio skonfigurowany).
Do tej pory było tak dobrze, ale zdarzają się przypadki, w których wadliwe dane wychodzą z dysku bez zgłaszania błędu przez dysk (patrz następny rozdział). Większość macierzy RAID może wykryć tę sytuację na podstawie informacji o parzystości, ale ich reakcja jest głupia: zamiast zgłaszać błąd i zatrzymać przekazywanie danych, po prostu ponownie obliczą parzystość na podstawie wadliwych danych i zapiszą nową parzystość do odpowiedniego dysk, w ten sposób oznaczając błędne dane jako prawidłowe na zawsze.
Czy to rozsądne zachowanie? O ile mi wiadomo, większość sprzętowych kontrolerów RAID5, a nawet Linux RAID md RAID, działa w ten sposób.
Nie wiem o korekcji błędów btrfs, ale ostatecznie powinieneś przeczytać dokumentację jeszcze raz, szczególnie jeśli używasz RAID btrfs.
Cicha zgnilizna bitów
Pomimo wszystkich wojen z płomieniami i (pseudo) dyskusji naukowych: Rzeczywistość zasadniczo różni się od teorii, a zgnilizna cichych bitów zdecydowanie się zdarza, chociaż teoria może twierdzić coś przeciwnego (cicha zgnilizna botów zwykle oznacza, że dane w pamięci sprzętowej ulegają uszkodzeniu bez urządzenia pamięci masowej zgłaszającego błąd podczas odczytu tych danych, ale dodam przerzucające bity w dowolnym miejscu ścieżki transmisji do tej definicji).
To, że tak się dzieje, nie jest moją osobistą opinią: przynajmniej Google, Amazon i CERN opublikowały szczegółowe białe księgi na ten temat. Artykuły są publicznie dostępne do pobrania bezpłatnie. Przeprowadzili systematyczne eksperymenty z kilkoma milionami dysków twardych i setkami tysięcy serwerów / urządzeń pamięci masowej, ponieważ albo mieli problemy z niewykrywalnym uszkodzeniem danych, albo dlatego, że chcieli wiedzieć, co zrobić, aby temu zapobiec, zanim to nastąpi.
Podsumowując, dane w ich farmach serwerów zostały uszkodzone z częstotliwością znacznie wyższą niż statystyki MTBF lub inna teoria, której można oczekiwać. Przez znacznie wyższe mam na myśli rzędy wielkości.
Tak więc cicha zgnilizna bitów, tj. Niewykryte uszkodzenie danych w dowolnym punkcie ścieżki transmisji, jest prawdziwym problemem życiowym.
Czas życia danych
Warren Young ma rację, gdy mówi, że dane wymiany mają krótki okres użytkowania. Chciałbym jednak dodać następującą uwagę: nie tylko dane (w sensie dokumentów) zamieniają się, ale (być może nawet bardziej prawdopodobne) części O / S lub innego działającego oprogramowania . Jeśli mam MP3 w swapie, mógłbym żyć z odrobiną przerzucania. Jeśli (z powodu ekstremalnej sytuacji) części mojego produkcyjnego oprogramowania serwera httpd są zamienione, w żadnym wypadku nie mogę żyć z odwracanym bitem, który później prowadzi do wykonania uszkodzonego kodu, jeśli nie zostanie wykryty.
Epilog
Dla mnie ZFS rozwiązuje te problemy, a ściślej odsuwa je od dysków do pamięci, a tym samym zmniejsza prawdopodobieństwo cichego zgnilizny bitów o kilka rzędów wielkości. Ponadto, jeśli jest poprawnie skonfigurowany (tj. Kopie lustrzane zamiast RAID), zapewnia czystą i rozsądną korektę błędów, która działa zgodnie z oczekiwaniami i może być łatwo zrozumiana.
Powiedziawszy to, pamiętaj, że nigdy nie uzyskasz absolutnego bezpieczeństwa. Osobiście ufam mojej pamięci ECC RAM bardziej niż moim dyskom i jestem przekonany, że ZFS dzięki kompleksowym sumom kontrolnym zmniejsza prawdopodobieństwo wystąpienia problemu o rząd wielkości. Chciałbym nigdy nie polecam korzystania ZFS bez ECC RAM, choć.
Oświadczenie: Nie jestem w żaden sposób związany z żadnym dostawcą lub programistą ZFS. Dotyczy to wszystkich wariantów (widelców) ZFS. Właśnie stałem się jego fanem w ostatnich dniach ...
źródło