Czy dane na dyskach twardych mogą być degradowane bez ostrzeżenia o uszkodzeniach?

Wszyscy martwimy się, że nasze dane i pliki są bezpieczne i nienaruszone, ale czy dane mogą zostać uszkodzone i dostępne dla użytkownika bez powiadomienia lub ostrzeżenia o problemie? Dzisiejszy post z pytaniami i odpowiedziami dla SuperUser jest odpowiedzią na niepokojące pytanie czytelnika.

Dzisiejsza sesja pytań i odpowiedzi przychodzi do nas dzięki uprzejmości SuperUser - poddziału Stack Exchange, opartego na społecznościach grupowania witryn z pytaniami i odpowiedziami.

Zdjęcie dzięki uprzejmości generalisation (Flickr).

Pytanie

Czytnik SuperUser topo morto chce wiedzieć, czy dane na dyskach twardych mogą ulec degradacji i uzyskać do nich dostęp bez ostrzeżenia o uszkodzeniu:

Czy jest możliwe, że fizyczna degradacja dysku twardego może spowodować, że bity "przerzucą się" w zawartości pliku bez powiadomienia systemu operacyjnego przez system operacyjny i powiadomienie o tym użytkownika podczas odczytu pliku? Na przykład, czy "p" (binarny 01110000) w pliku tekstowym ASCII zmieni się na "q" (binarny 01110001), a kiedy użytkownik otworzy plik, zobaczy "q" nie wiedząc, że wystąpiła awaria?

Jestem zainteresowany odpowiedziami dotyczącymi FAT, NTFS lub ReFS (jeśli ma to znaczenie). Chcę wiedzieć, czy systemy operacyjne chronią użytkowników przed tym, czy też powinniśmy sprawdzać nasze dane pod kątem rozbieżności między kopiami w czasie.

Czy dane na dyskach twardych mogą ulec degradacji i uzyskać do nich dostęp bez ostrzeżenia o uszkodzeniach?

Odpowiedź

Współpracownik SuperUser Guntram Blohm ma dla nas odpowiedź:

Tak, jest coś, co nazywa się zgnilizną. Ale nie, nie wpłynie to na użytkownika niezauważalnie.

Kiedy dysk twardy zapisuje sektor na półmiskach, nie tylko zapisuje bity w ten sam sposób, w jaki są przechowywane w pamięci RAM, używa kodowania, aby upewnić się, że nie ma sekwencji tego samego bitu, które są zbyt długie. Dodaje także kody ECC, które pozwalają mu naprawiać błędy, które mają wpływ na kilka bitów i wykrywać błędy, które dotyczą więcej niż kilku bitów.

Gdy dysk twardy odczytuje sektor, sprawdza te kody ECC i naprawia dane, jeśli to konieczne (i jeśli to możliwe). To, co dzieje się dalej, zależy od okoliczności i oprogramowania wewnętrznego dysku twardego, na które ma wpływ nazwa dysku.

Jeśli sektor można odczytać i nie ma problemów z kodem ECC, to jest on przekazywany do systemu operacyjnego.

Jeśli sektor można łatwo naprawić, naprawioną wersję można zapisać na dysk, odczytać, a następnie zweryfikować, aby ustalić, czy błąd był losowy (tj. Promieniowanie kosmiczne, itp.) Lub czy wystąpił systematyczny błąd w mediach.

Jeśli dysk twardy wykryje, że wystąpił błąd z nośnikiem, ponowne przydzielenie sektora.

Jeśli po kilku próbach odczytu nie można odczytać ani skorygować sektora (na dysku twardym oznaczonym jako dysk twardy RAID), dysk twardy zrezygnuje, ponownie przydzielony sektor i powiadomi kontroler, że wystąpił problem . Opiera się on na kontrolerze RAID w celu rekonstrukcji sektora z innych elementów RAID i zapisania go na nieudanym dysku twardym, który następnie przechowuje go w ponownie przydzielonym sektorze (który, mam nadzieję, nie ma problemu).

Jeśli nie można odczytać lub skorygować sektora na dysku twardym komputera stacjonarnego, dysk twardy podejmie więcej prób jego odczytania. W zależności od jakości dysku twardego może to wymagać zmiany położenia głowicy, sprawdzenia, czy są jakieś bity, które przewracają się podczas wielokrotnego odczytu, sprawdzania, które bity są najsłabsze i kilka innych rzeczy. Jeśli którakolwiek z tych prób się powiedzie, dysk twardy ponownie przydzieli sektor i odtworzy naprawione dane.

Jest to jedna z głównych różnic pomiędzy dyskami twardymi sprzedawanymi jako dyski twarde "desktop", "NAS / RAID" lub "video surveillance". Dysk twardy RAID może po prostu szybko się poddać i zmusić kontroler do naprawy sektora, aby uniknąć opóźnień po stronie użytkownika. Dysk twardy na pulpicie będzie nadal próbował, ponieważ odczekanie użytkownika przez kilka sekund jest prawdopodobnie lepsze niż informowanie go o utracie danych. Ponadto dysk twardy wideo zapewnia stałą prędkość przesyłania danych w większym stopniu niż odzyskiwanie po błędzie, ponieważ uszkodzona ramka zwykle nie zostanie zauważona.

W każdym razie dysk twardy będzie wiedział, czy było trochę zgnilizna, zazwyczaj będzie odzyskiwał się z niego, a jeśli nie, powie kontrolerowi, który z kolei powie kierowcy, który następnie powie systemowi operacyjnemu. Następnie system operacyjny musi przedstawić błąd użytkownikowi i podjąć odpowiednie działania. Właśnie dlatego cybernard mówi:

Nigdy nie widziałem samemu błędu, ale widziałem mnóstwo dysków twardych, na których zawiodły całe sektory.

Dysk twardy będzie wiedział, czy coś jest nie tak z sektorem, ale nie będzie wiedział, które bity zawiodły. Pojedynczy bit, który zawiódł, zawsze będzie przechwycony przez ECC.

Należy zauważyć, że chkdsk i systemy plików automatycznie naprawiające się nie odnoszą się do naprawy danych w plikach. Są one ukierunkowane na korupcję w samej strukturze systemu plików, na przykład na różnicę wielkości pliku między wpisem do katalogu a liczbą przydzielonych bloków. Funkcja samouzdrawiania systemu NTFS wykrywa uszkodzenia strukturalne i zapobiega dalszemu wpływowi na dane, ale nie naprawi żadnych danych, które są już uszkodzone.

Istnieją oczywiście inne powody, dla których dane mogą zostać uszkodzone. Na przykład, zła pamięć RAM na kontrolerze może zmienić dane, zanim zostanie nawet wysłana na dysk twardy. W takim przypadku żaden mechanizm na dysku twardym nie wykryje ani nie naprawi danych, a to może być jeden z powodów uszkodzenia struktury systemu plików. Inne powody to błędy oprogramowania, blackout podczas zapisywania na dysk twardy (choć jest to rozwiązywane przez system plików) lub złe sterowniki systemu plików (sterownik NTFS w systemie Linux domyślnie był przeznaczony tylko do odczytu przez długi czas, ponieważ system NTFS został poddany inżynierii wstecznej, nieudokumentowane, a deweloperzy nie ufali własnemu kodowi).

Miałem taki scenariusz, gdy aplikacja zapisywałaby wszystkie swoje pliki na dwóch różnych serwerach w dwóch różnych centrach danych, aby zachować roboczą kopię danych dostępnych w każdych okolicznościach. Po kilku miesiącach zauważyliśmy, że około 0,1% wszystkich skopiowanych plików nie pasuje do sumy kontrolnej MD5, którą aplikacja zapisała w swojej bazie danych. Okazało się, że jest to wadliwy kabel światłowodowy między serwerem a siecią SAN.

Te inne przyczyny powodują, że niektóre systemy plików, takie jak ZFS, przechowują dodatkowe informacje o sumie kontrolnej w celu wykrycia błędów. Zostały one zaprojektowane, aby chronić Cię przed wieloma innymi rzeczami, które mogą pójść nie tak, jak tylko gniją.

Czy masz coś do dodania do wyjaśnienia? Dźwięk w komentarzach. Chcesz przeczytać więcej odpowiedzi od innych użytkowników Stack Exchange, którzy znają się na technologii? Sprawdź cały wątek dyskusji tutaj.