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 SuperUser Q & A ma odpowiedź na niepokojące pytanie czytelnika.

Dzisiejsze pytanie &Sesja odpowiedzi przychodzi do nas dzięki uprzejmości SuperUser - poddziału Stack Exchange, opartego na społecznościach grupy Q & A.

Zdjęcie dzięki uprzejmości uogólniania( 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 twardego dysku może spowodować, że bity "przerzucą się" w zawartości plikubez zauważenia zmiany przez system operacyjny i powiadamiania o tym użytkownika podczas odczytu pliku? Na przykład, czy "p"( binarny 01110000) w pliku tekstowym ASCII zmieni się na "q"( binarny 01110001), to 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ź Odpowiedział

SuperUser Guntram Blohm ma odpowiedź dla nas:

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

Kiedy dysk twardy zapisuje sektor na półmiskach, nie zapisuje bitów tylko w ten sam sposób, w jaki są one 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 również kody ECC, które pozwalają na naprawę błędów, które mają wpływ na kilka bitów i wykrywanie błędów, które mają wpływ na więcej niż kilka 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óry ma wpływ nazwa dysku.

• Jeśli można odczytać sektor i nie ma problemów z kodem ECC, to jest on przekazywany do systemu operacyjnego.
• Jeśli sektor można łatwo naprawić, naprawiona wersja może zostać zapisana na dysku, odczytana, a następnie sprawdzona w celu ustalenia, czy błąd był losowy( np. Promienie kosmiczne, itp.) Lub czy wystąpił systematyczny błąd w mediach.
• Jeśli na dysku twardym zostanie wykryte wystąpienie błędu z nośnikiem, nastąpi ponowne przydzielenie sektora.
• Jeśli sektor nie może zostać odczytany ani skorygowany po kilku próbach odczytu( na dysku twardym oznaczonym jako dysk twardy RAID), dysk twardy zrezygnuje, ponownie przydzielony sektor i powie kontrolerowi, że wystąpiłproblem. Opiera się 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 reallocated sektorze( który, mam nadzieję, nie ma problemu).
• Jeśli nie można odczytać lub skorygować sektora na dysku twardym komputera stacjonarnego, dysk twardy wykona 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 "monitoringu wideo".Dysk twardy RAID może po prostu szybko się poddać i zmusić kontroler do naprawy sektora, aby uniknąć opóźnień po stronie użytkownika. Twardy dysk stacjonarny będzie nadal próbował wielokrotnie, ponieważ posiadanie przez użytkownika kilkusekundowego opóźnienia jest prawdopodobnie lepszym rozwiązaniem niż poinformowanie ich o utracie danych. Ponadto dysk twardy wideo zapewnia stałą szybkość transmisji danych, a nie usuwanie błędów, ponieważ uszkodzona ramka zwykle nie zostanie zauważona.

W każdym razie dysk twardy będzie wiedział, czy nastąpił zgnilizna bitów, zazwyczaj odzyska od niego, a jeśli nie, powie kontrolerowi, który z kolei przekaże sterownikowi, który poinformuje system operacyjny. Następnie system operacyjny musi przedstawić błąd użytkownikowi i podjąć odpowiednie działania. To dlatego cybernard mówi:

• Sam nigdy nie byłem świadkiem pojedynczego błędu, ale widziałem wiele 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 pamiętać, że chkdsk i systemy plików automatycznie naprawiające się nie zajmują się naprawą danych w plikach. Są one ukierunkowane na korupcję w samej strukturze systemu plików, na przykład na różnicę w wielkości pliku między wpisem do katalogu a liczbą przydzielonych bloków. Funkcja samouzdrawiania systemu plików NTFS wykrywa uszkodzenia strukturalne i zapobiega dalszemu wpływowi na dane, ale nie naprawi żadnych danych, które już zostały 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( chociaż jest to rozwiązywane przez rejestrowanie w systemie 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ć działającą kopię danych 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 chcesz coś dodać 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.