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 zawiera odpowiedź na pytanie zadane przez zmartwionego czytelnika.
Dzisiejsza sesja pytań i odpowiedzi przychodzi do nas dzięki uprzejmości SuperUser - poddziału Stack Exchange, społecznościowego forum z pytaniami i odpowiedziami.
Zdjęcie dzięki uprzejmości generalisation (Flickr).
Czytnik SuperUser topo morto chce wiedzieć, czy dane na dyskach twardych mogą się pogorszyć 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), 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 wpływ). 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?
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.
Gdy dysk twardy zapisuje sektor na półmiskach, nie zapisuje tylko bitów 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.
Kiedy 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 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ć, naprawiona wersja może zostać zapisana na dysku, odczytywana, następnie weryfikowana w celu ustalenia, czy błąd był losowy (tj. Promieniowanie kosmiczne itp.) Lub w przypadku systematycznego błędu z nośnikiem.
- Jeśli dysk twardy wykryje, że wystąpił błąd z nośnikiem, ponownie przydziela sektor.
- 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ę 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 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. 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 było trochę zgnilizna, zazwyczaj odzyskuje się z niego, a jeśli nie, to 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, które same się naprawiają, 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ć roboczą kopię danych dostępną 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.
