Czy bit rot na dyskach twardych to prawdziwy problem? Co można z tym zrobić?

Znajomy rozmawia ze mną o problemie zgnilizny bitów na dyskach losowo przerzucających, niszczących dane. Niesamowicie rzadkie, ale z wystarczającą ilością czasu może to stanowić problem i nie można go wykryć.

Dysk nie uznałby go za zły sektor, a kopie zapasowe po prostu pomyślałyby, że plik się zmienił. Nie jest wymagana suma kontrolna do sprawdzenia integralności. Nawet w konfiguracji RAID wykryto by różnicę, ale nie byłoby sposobu, aby dowiedzieć się, która kopia lustrzana jest poprawna.

Czy to prawdziwy problem? A jeśli tak, co można z tym zrobić? Mój przyjaciel poleca ZFS jako rozwiązanie, ale nie wyobrażam sobie spłaszczania naszych serwerów plików w pracy, instalowania systemów Solaris i ZFS.

Po pierwsze: Twój system plików może nie mieć sum kontrolnych, ale sam dysk twardy je ma. Na przykład SMART. Oczywiście, kiedy odrobinę za dużo zostało odrzuconych, błędu nie da się naprawić. A jeśli naprawdę masz pecha, bity mogą się zmieniać w taki sposób, że suma kontrolna nie stanie się nieważna; wtedy błąd nawet nie zostanie wykryty. Mogą się zdarzyć nieprzyjemne rzeczy ; ale twierdzenie, że losowe przewracanie bitów natychmiast uszkodzi dane, jest fałszywe.

Jednak tak, gdy umieścisz biliony bitów na dysku twardym, nie pozostaną one na zawsze; to prawdziwy problem! ZFS może sprawdzać integralność za każdym razem, gdy dane są odczytywane; jest to podobne do tego, co robi sam dysk twardy, ale jest to kolejne zabezpieczenie, dla którego poświęcasz trochę miejsca, dzięki czemu zwiększasz odporność na uszkodzenie danych.

Gdy twój system plików jest wystarczająco dobry, prawdopodobieństwo wystąpienia błędu bez wykrycia staje się tak niskie, że nie musisz się tym dłużej przejmować i możesz zdecydować, że sumy kontrolne wbudowane w używany format przechowywania danych to niepotrzebny.

Tak czy inaczej: nie, nie jest niemożliwe do wykrycia .

Ale system plików sam w sobie nigdy nie może być gwarancją, że każdą awarię można naprawić; to nie jest srebrna kula. Nadal musisz mieć kopie zapasowe i plan / algorytm, co zrobić, gdy wykryty zostanie błąd.

Tak, to problem, głównie w miarę wzrostu rozmiarów napędów. Większość dysków SATA ma współczynnik URE (nieusuwalny błąd odczytu) wynoszący 10 ^ 14. Lub na każde 12 TB danych odczytanych statystycznie producent dysku twierdzi, że dysk zwróci błąd odczytu (zwykle można je sprawdzić w specyfikacjach napędu). Napęd będzie nadal działał dobrze dla wszystkich innych części napędu. Dysk Enterprise FC i SCSI ma zwykle współczynnik URE 10 ^ 15 (120 TB) wraz z niewielką liczbą dysków SATA, co pomaga go zmniejszyć.

Nigdy nie widziałem, aby dyski przestały się obracać w tym samym czasie, ale miałem problem z woluminem raid5 (5 lat temu z dyskami PATA konsumenckimi 5400 RPM). Dysk ulega awarii, jest oznaczony jako martwy i następuje przywrócenie dysku zapasowego. Problem polega na tym, że podczas przebudowy drugi dysk nie może odczytać tego małego bloku danych. W zależności od tego, kto przeprowadzi nalot, cały tom może być martwy lub tylko ten mały blok może być martwy. Zakładając, że tylko jeden blok jest martwy, jeśli spróbujesz go odczytać, pojawi się błąd, ale jeśli do niego napiszesz, napęd ponownie mapuje go w inne miejsce.

Istnieje wiele metod ochrony przed: raid6 (lub równoważny), który chroni przed awarią podwójnego dysku jest najlepszy, dodatkowe to system plików obsługujący URE, taki jak ZFS, wykorzystujący mniejsze grupy rajdowe, więc statystycznie masz mniejsze szanse na trafienie na dysk URE limity (dublowanie dużych dysków lub mniejsze dyski RAID5), czyszczenie dysku i SMART również pomaga, ale nie jest samo w sobie ochroną, ale jest stosowane jako dodatek do jednej z powyższych metod.

Zarządzam prawie 3000 wrzecionami w tablicach, a tablice stale szorują dyski w poszukiwaniu ukrytych URE. I otrzymuję ich dość stały strumień (za każdym razem, gdy go znajdzie, naprawia go przed awarią napędu i ostrzega mnie), gdybym używał raid5 zamiast raid6, a jeden z napędów był całkowicie martwy ... mieć kłopoty, jeśli trafią w określone miejsca.

Dyski twarde zasadniczo nie kodują bitów danych jako pojedynczych domen magnetycznych - producenci dysków twardych zawsze byli świadomi, że domeny magnetyczne mogą się odwracać i wbudować wykrywanie błędów i korekcję dysków.

Jeśli nieco się przewróci, dysk zawiera wystarczającą ilość nadmiarowych danych, które może i zostanie poprawiony przy następnym czytaniu tego sektora. Możesz to zobaczyć, jeśli sprawdzisz statystyki SMART na dysku jako „Naprawialny poziom błędu”.

W zależności od szczegółów dysku powinien on być w stanie odzyskać nawet więcej niż jeden odwrócony bit w sektorze. Będzie limit liczby przerzucanych bitów, które można dyskretnie skorygować, i prawdopodobnie inny limit liczby przerzucanych bitów, które mogą zostać wykryte jako błąd (nawet jeśli nie ma już wystarczającej ilości wiarygodnych danych, aby to naprawić)

Wszystko to składa się na fakt, że dyski twarde mogą automatycznie korygować większość pojawiających się błędów i niezawodnie wykrywają większość pozostałych. Musiałbyś mieć dużą liczbę błędów bitowych w jednym sektorze, które wszystkie miały miejsce przed ponownym odczytaniem tego sektora, a błędy musiałyby być takie, aby kody wykrywania błędów wewnętrznych ponownie widziały je jako prawidłowe dane, zanim kiedykolwiek miałby cichą porażkę. Nie jest to niemożliwe i jestem pewien, że firmy prowadzące bardzo duże centra danych widzą, że tak się dzieje (a raczej tak się dzieje i nie widzą, że tak się dzieje), ale z pewnością nie jest to tak duży problem, jak mogłoby się wydawać.

Współczesne dyski twarde (od 199x) mają nie tylko sumy kontrolne, ale także ECC, które mogą wykryć i skorygować dość „losowy” zgniliznę bitów. Zobacz: http://en.wikipedia.org/wiki/SMART .

Z drugiej strony niektóre błędy w oprogramowaniu sprzętowym i sterownikach urządzeń mogą również uszkodzić dane w rzadkich przypadkach (w przeciwnym razie wychwytuje błędy), co byłoby trudne do wykrycia, jeśli nie masz sum kontrolnych wyższego poziomu. Wczesne sterowniki urządzeń dla SATA i NIC miały uszkodzone dane zarówno w systemie Linux, jak i Solaris.

Sumy kontrolne ZFS mają głównie na celu usunięcie błędów w oprogramowaniu niższego poziomu. Nowsze systemy pamięci / baz danych, takie jak Hypertable, mają również sumy kontrolne dla każdej aktualizacji, aby uchronić się przed błędami w systemach plików :)

Teoretycznie jest to powód do niepokoju. Praktycznie rzecz biorąc, jest to jeden z powodów, dla których przechowujemy kopie zapasowe dzieci / rodziców / dziadków. Roczne kopie zapasowe muszą być przechowywane przez co najmniej 5 lat, IMO, a jeśli masz problem z cofaniem się dalej, plik nie jest oczywiście tak ważny.

O ile nie masz do czynienia z bitami, które potencjalnie mogłyby czynić czyjś mózg , nie jestem pewien, czy ryzyko w porównaniu z nagrodą jest aż do zmiany systemów plików.

Tak, to jest problem.

Jest to jeden z powodów, dla których RAID6 jest teraz w modzie (wraz ze wzrostem rozmiarów HD wydłuża czas na odbudowę macierzy). Posiadanie dwóch bloków parzystości pozwala na dodatkową kopię zapasową.

Systemy RAID wykonują teraz również czyszczenie RAID, które okresowo odczytuje bloki dysku, sprawdza parytety i zastępuje je, jeśli stwierdzi, że blok jest zły.

Jeśli chodzi o oświadczenie OP dotyczące RAID, nie rozumiem, jakie dane są dobre, a jakie złe.

Kontrolery RAID używają co najmniej (nieparzystych / parzystych) bitów parzystości na każdym pasku danych. To jest na wszystko; paski danych na dysku i paski danych parzystości (kopii zapasowej).

Oznacza to, że dla każdego typu macierzy RAID, w których zastosowano striping w celu nadmiarowości (RAID 5/6), kontroler może dokładnie stwierdzić, czy oryginalny pasek danych zmienił się, a także, czy pasek danych nadmiarowości zmienił się.

Jeśli wprowadzisz drugi nadmiarowy pasek, taki jak RAID6, musisz mieć 3 paski danych, na trzech różnych dyskach zostaną uszkodzone, a wszystkie odpowiadają tym samym faktycznym danym pliku. Pamiętaj, że większość systemów RAID używa stosunkowo małych pasków danych (128 kb lub mniej), więc szanse na „zgniliznę bitów” w linii do tego samego 128 kb, tego samego pliku, są praktycznie niemożliwe.

Tak, to prawdziwy problem na świecie, ale pytanie brzmi, czy powinieneś się tym martwić, czy nie.

Jeśli masz tylko dysk twardy pełen zdjęć, może nie być wart wysiłku. Jest pełen ważnych danych naukowych, może to być inna historia, masz pomysł.