Jaka jest ziarnistość dysku twardego URE (nieodwracalny błąd odczytu)?


8

tl; dr w przypadku a URE występuje na dysku twardym, czy utracę 1 bit, 1 bajt lub rozmiar sektora (512 bajtów lub 4096 bajtów AF)? a jeśli to możliwe, wyjaśnij dlaczego?

Tło: Pojawia się pytanie, kiedy dysk twardy ma problem z odczytem danych. Z pewnością dysk może zawieść całkowicie pozostawiając wszystkie utracone dane (DISK FAIL), ale sprawa Pytam o tutaj jest tak, że gdy tylko mniejsza jego część zostanie utracona (URE, nie można naprawić błędu odczytu).

Mimo że szukałem informacji dotyczących URE, na pewno niewiele się dowiedziałem. Może to mieć swoją przyczynę w tym, że to, co dzieje się wewnętrznie w napędzie, tj. To, co jest ukryte przed bezpośrednią interakcją użytkownika, jak korekta ECC, jest dla mnie trudne do odniesienia się do tego, co mam dostęp jako użytkownik - sektorów.

Wyobraźmy sobie, że dysk twardy ma problemy z odczytem danych.

W tej sytuacji na pewno musi to oznaczać:

  • (a) niektórych bitów sektora nie można odczytać, lub
  • (b) wszystkie bity mogą być odczytywane, ale nie przechodzą testu sumy kontrolnej (oczywiście oczekując kłopotów sektor 4096 bajtów to nie tylko 8 * 4096 bitów, ale niektóre dodatkowe bity / bajt do sprawdzania / korekcji błędów (tj. bity parzystości ) (c) ????

Nie sądzę, że kiedy jesteśmy w sytuacji, w której wystąpiła kombinacja (a) i (b) i nie można wykonać wiarygodnego rekonstrukcji bajtów sektora 4096, to nadmierne jest zakładanie, że koniecznie wszystkie z nich są garpage , gdybyśmy byli świadomi logiki korekcji błędów między dyskami wewnętrznymi, moglibyśmy powiedzieć: „wygląd czegoś nie sprawdza się, a przy dobrej zmianie co najmniej 1,2,3, n bitów / bajtów danych blokowych jest„ zły ” „ Gdybyśmy nadmiarowo zapisywali „cześć, cześć ....., cześć” ciągi bajtów ASCII w tym sektorze, wciąż moglibyśmy mieć uczciwą kolejność „cześć, witaj ....”, zanim będzie „... Uellohello ... ”(tj.„ E ”- & gt;„ U ”).

Jaka jest więc szczegółowość URE?

AKTUALIZACJA: pojawił się komentarz dotyczący idei złego sektora (i sugerujący, że odzwierciedla to szczegółowość wydarzenia URE. Nie jest to absurdalne, sugerować to i być może można wykorzystać w odpowiedzi na to pytanie. Jednak po prostu przeczytałem inne powiązane pytanie z pytaniem o oczekujących nieczytelnych sektorach (tutaj https://unix.stackexchange.com/questions/1869/how-do-i-make-my-disk-unmap-pending-unreadable-sectors ) co prowadzi mnie do wniosku, że w niektórych scenariuszach rzeczywiście istnieje bardziej rozmyta linia między danymi utraconymi w przypadku URE.


Zwykle jest to kilkadziesiąt tysięcy bloków uszkodzonych naraz w przypadku rozbitej głowy. Jeśli jest to kurz itp., Dostęp do pobliskich bloków może spowodować uszkodzenie. Tak więc rzadko można tak łatwo zrekonstruować część większego obszaru.
JamesRyan

@JamesRyan dobra wskazówka, zawsze może być gorzej. Może po prostu pytałem o najmniej zły przypadek (to znaczy tylko o utratę sektora, lub, jak częściowo rozwiązano w dobrych odpowiedziach, część danych sektorów, w zależności od rodzaju wewnątrz niego). może trzeba wiedzieć więcej o genezie nieczytelnych błędów (i ich trwałości, tj. losowej zgnilizny, czy zderzeniu czołowym). Ale chcemy tutaj odpowiadać na pytania, więc niepotrzebnie nie komplikowałem już tego pytania
humanityANDpeace

Odpowiedzi:


8

Kod korekcji błędów na dysku twardym to dodatkowy fragment danych związanych z każdym sektorem sprzętu. Podczas pisania oprogramowanie układowe dysku oblicza te dane i zapisuje je wraz z danymi użytkownika. Podczas czytania oprogramowanie układowe odczytuje ECC wraz z danymi i sprawdza je razem.

W przypadku tradycyjnego dysku twardego sektor sprzętowy ma 512 bajtów. Dla dysku Advanced Format jest to 4K bajtów (nie ma znaczenia, czy dysk prezentuje 512-bajtowy czy 4-bajtowy sektor na interfejsie, tj. 512e vs. 4kn).

Wynik sprawdzenia po przeczytaniu ma zasadniczo trzy możliwe wyniki:

  • sektor został odczytany bez błędu. W rzeczywistości nie jest to powszechne na nowoczesnych dyskach twardych; gęstości bitowe są takie, że zależą od pracy ECC.

  • sektor został odczytany z możliwymi do skorygowania błędami. Jak sugerowano powyżej, nie jest to rzadkie; oczekuje się. Napęd zwraca dane, z zastosowaną korekcją błędów, do użytkownika.

  • sektor został odczytany, ale było zbyt wiele „błędnych bitów”; błędów nie można naprawić.

W tym drugim przypadku napęd zwykle nie zwraca żadnej zawartości; po prostu zwraca status wskazujący błąd. Dzieje się tak, ponieważ nie można wiedzieć, które bity są podejrzane, nie mówiąc już o ich wartościach. Dlatego cały sektor (bity ECC i wszystkie) jest nieufny. Nie można określić, która część złego sektora jest zła, nie mówiąc już o tym, jaka powinna być jego zawartość. ECC to „gestalt”, który jest obliczany dla całej zawartości sektora, a jeśli nie pasuje, to cały sektor nie jest dopasowany.

SpinRite działa po prostu próbując ciągle odczytywać zły sektor, korzystając z funkcji „odczytu konserwacyjnego”, która zwraca dane (ale bez bitów ECC), nawet jeśli dysk mówi „błąd niemożliwy do naprawienia”. Jak powiedziano w opisie powiązanym przez DavidPostill, może się udać bezbłędnie (w rzeczywistości „poprawialnie” jest bardziej prawdopodobne) czytać; lub może być w stanie wydedukować, zasadniczo przez uśrednienie razem zwracanych bitów, rozsądne przypuszczenie co do zawartości sektora. Nie ma większej możliwości precyzyjnego poprawiania błędów za pomocą ECC niż napęd; to jest matematycznie niemożliwe.


Czy nadal jest matematycznie niemożliwe, jeśli dane wewnątrz ładunku 4096 bajtów same w sobie są kompilacją ładunku 4000 bajtów, a kolejne 96 bajtów ECC na górze? (na przykład dlatego, że chciałem poświęcić pojemność na odzyskanie układu magazynu danych?).
humanityANDpeace

domyślam się, że jest to matematycznie niemożliwe pod domyślnym założeniem, że nie ma dalszej redundancji wewnątrz danych, prawda? - a także świetna odpowiedź!
humanityANDpeace

1
Pewnie. W tym momencie jest to kolejny niewiarygodny kanał, ale jeśli jest w nim wystarczająca nadmiarowość. Chodzi o to, że standardowe sterowniki dysków systemu operacyjnego w ogóle nie podadzą zawartości sektora, jeśli dysk uzna, że ​​błędy są nie do naprawienia. RAID-5 i podobne systemy parzystości robią to samo na „warstwie zewnętrznej” niż wewnątrz pól danych istniejących sektorów.
Jamie Hanrahan

„catch” ze sterownikami os, które zwracają (na żądanie) wszystkie, nawet niezweryfikowane dane, stanowi problem, jako użytkownik nie będący użytkownikiem systemu Windows zapytałem o to konkretnie unix.stackexchange.com/questions/228254/…
humanityANDpeace

3

Jaka jest szczegółowość URE?

Nieodwracalne błędy odczytu (URE) to błędy odczytu sektorowego. Jeśli sektora nie można odczytać bez błędu, nie ma znaczenia, czy był to tylko 1 bajt, czy wszystkie bajty sektora.

Granularność to rozmiar sektora .

Nawet jeśli tylko 1 bajt się nie powiedzie, nie normalnie pobrać dowolne dane z sektora bez użycia specjalistycznego oprogramowania.


Czy można odzyskać dane z uszkodzonego sektora?

SpinRite mówi:

SpinRite jest nawet w stanie odzyskać większość danych w sektorze, którego nigdy nie da się dokładnie odczytać, a które inne oprogramowanie użytkowe odrzuca w całości.

Widzieć Jak SpinRite odzyskuje nieczytelne dane .


Zrzeczenie się.

Nie jestem związany z SpinRite w żaden sposób, a ja nigdy z niego nie korzystałem.


1
Sądzę, że to dobra odpowiedź, nie dlatego, że koniecznie zgadzam się, że w przypadku URE konieczne jest całkowite utratę sektora (czyli wszystkich 4k danych), ale ponieważ dysk twardy może odrzucić nawet tę część „zły sektor”, który nadal miałby wartość. Prezentacja argumentów SpinWrite podtrzymuje ten pomysł, więc odpowiedź oferuje również więcej wglądu, świetnie.
humanityANDpeace

2

Nie ma czegoś takiego, jak „nie można odczytać trochę”, chyba że masz naprawdę ciężki błąd sprzętowy, jak gdyby głowa nie była w stanie znaleźć właściwej ścieżki lub ścieżka serwo jest uszkodzona i nie można znaleźć właściwego sektora . Oczywiście w obu przypadkach miałbyś przynajmniej cały nieczytelny sektor.

W przeciwnym razie zawsze dostajesz z powrotem kawałki, są po prostu prawdopodobnie niepoprawne kawałki. Tutaj pojawia się kod do poprawiania błędów; dodaje pewną liczbę dodatkowych bitów ECC do każdego sektora, tak że każda prawidłowa kombinacja bitów danych i bitów ECC przestrzega pewnej reguły algebraicznej. Jeśli wszystkie bity zostały odczytane poprawnie, kod zostanie sprawdzony, a dane mogą zostać przekazane bezpośrednio. Jeśli niewielka liczba bitów została odczytana niepoprawnie, kod ECC może zostać użyty do dokładnego określenia, które z nich i naprawienia ich, więc wszystkie dane są przekazywane poprawnie. Jeśli większa liczba bitów została odczytana nieprawidłowo, kod ECC może to wykryć było błąd, ale nie ma już wystarczającej ilości informacji, aby się zorientować który bity są nieprawidłowe; jest to nieodwracalny błąd odczytu. Jeśli bardzo duża liczba bitów jest niepoprawnie odczytywana, wtedy kod może potwierdzić poprawność „przez przypadek”, a napęd zwróci uszkodzone dane, ale przy wystarczającej liczbie bitów ECC prawdopodobieństwo takiego zdarzenia może być tak małe, jak chcesz.

Aby odpowiedzieć na pytanie, na które myślę, że się pojawiałeś - jeśli wystąpił częściowy błąd odczytu, ale było wystarczająco dużo informacji, aby dowiedzieć się, gdzie wystąpił błąd, to można go również poprawić, a komputer w ogóle nie zobaczy żadnego błędu . To dzieje się stale. Nieskorygowany błąd występuje, gdy nie można określić, które bity danych są poprawne, a które nie, a ponieważ kod korygujący błędy jest obliczany dla sektora, dzieje się to przy ziarnistości sektora.


1

Po przyjrzeniu się i zainspirowaniu odpowiedzią https://superuser.com/a/969917/160771 z https://superuser.com/users/337631/davidpostill

Chciałbym odpowiedzieć, przedstawiając nieco rozszerzającą się alternatywną odpowiedź. Po pierwsze, prawdą jest, że dysk twardy i jego oprogramowanie są źródłem zdarzenia URE, czyli zdarzenia, którego nie można odczytać. Ponadto prawdą jest, że dane zapisywane są na dysku w sektorach 512 lub 4096 bajtów użytecznych danych i około 50 lub odpowiednich 100 bajtów dodatkowych danych, które powinny umożliwić sprawdzanie i poprawianie błędów.

Mówienie o URE odbywa się zatem naturalnie w kontekście sektora dysku twardego. Termin zły sektor jest z pewnością nieco powiązane, ale nie identyczne z sytuacją, która ma miejsce, gdy mamy sektor URE.

Sektor, w którym niektóre problemy można odczytać bez błędów, niekoniecznie jest całkowicie bez znaczenia. Możliwe, że rzeczywiście wszystkie 4096 danych uległo uszkodzeniu, ale może również być uszkodzone tylko 1 bit więcej niż można było wiarygodnie skorygować (za pośrednictwem dodatkowych danych ECC dodanych do każdego sektora).

W przypadkach, w których tylko niektóre bardzo niewiele bajtów więcej niż hdd był w stanie poprawić, zostały uszkodzone zmiany, które ułamek 4096 bajtów nadal mają znaczące dane.

Przykładem może być to, że 4096 reprezentuje bajty ASCII składające się z 2 zdań. Wtedy możliwe jest, że zdanie 1 kapelusza lub więcej jest całkowicie nienaruszone. Możliwe też, że co druga lub trzecia litera została usunięta. Jeśli dane 4096 zostaną utracone w zdarzeniu URE, zależy to od interpretacji i zależy od danych. Można sobie wyobrazić, że same dane miały kolejną warstwę powłoki ECC, która pozwoliłaby na dalsze odzyskiwanie.

Dlatego dobrze, że większość firmware traktuje sektory URE inaczej niż sektory złe:

Zazwyczaj automatyczne remapowanie sektorów ma miejsce tylko wtedy, gdy sektor jest zapisany. Logika tego jest przypuszczalnie taka, że ​​nawet jeśli sektor nie może być odczytany normalnie, nadal może być czytelny za pomocą metod odzyskiwania danych.   (z https://en.wikipedia.org/wiki/Bad_sector )

Lub, w dużym stopniu, może to oznaczać, że część sektora nadal zawiera użyteczne dane.


Pamiętaj, że artykuł jest oznaczony jako „wymaga uwagi eksperta”, „prawdopodobnie zawiera oryginalne badania” i to konkretne stwierdzenie jest oznaczone jako „potrzebne źródło”. Sposób, w jaki jest napisany („przypuszczalnie”?), Sprawia, że ​​brzmi to podobnie, jak ktoś spekuluje, a nie coś, co można poddać obróbce przy pomocy wysokiej jakości materiału źródłowego.
a CVn
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.