Błędy odczytu dysku twardego, które… przestają?

Moja historia zaczyna się po prostu. Mam lekki serwer z systemem Arch Linux, który przechowuje większość danych na macierzy RAID-1 złożonej z dwóch dysków SATA. Działał bez żadnych problemów przez około 4 miesiące. Nagle zacząłem otrzymywać błędy odczytu na jednym z dysków. Zawsze wiadomości wyglądały podobnie do tych:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

Każdy błąd narzekał na inny numer sektora i towarzyszyło mu kilka sekund opóźnienia dla użytkownika (mnie) uzyskującego dostęp do dysku.

Sprawdziłem wyjście smartctl i zobaczyłem następujące wyjście (obcięte części nieistotne):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

Spoglądając wstecz na dzienniki, zauważyłem, że błędy występowały przez kilka dni, głównie podczas tworzenia kopii zapasowych, ale także często podczas bardzo lekkiego użytkowania (co oznacza, że ​​co 5 próbowałem zapisać plik tekstowy). Doszedłem do wniosku, że mój dysk umiera, że ​​RAID-1 odpowiednio go obsługuje i że nadszedł czas, aby zamówić dysk zastępczy. Zamówiłem nowy dysk.

Ku mojemu zaskoczeniu, dzień później błędy ... ustały. Nie zrobiłem nic, aby je naprawić. Nie uruchomiłem się ponownie, nie przełączyłem dysku w tryb offline, nic. Ale błędy właśnie ustały.

W tym momencie, ciekawy, czy uszkodzone sektory znajdują się teraz w bezczynnych częściach dysku, wyjąłem dysk z RAID, włożyłem go z powrotem do RAID i pozwoliłem mu zakończyć pełną ponowną synchronizację. Ponowna synchronizacja zakończyła się bez błędów, 9 godzin później (dyski 2 TB trwają chwilę).

Również wyjście smartctl nieco się zmieniło, jak następuje:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

Część tego, co mnie dziwi, jest oczywiście: „Od kiedy to złe dyski same się naprawiają?”

Przypuszczam, że możliwe jest, że bardzo mały obszar dysku spontanicznie się zepsuł, a dysk po prostu zajął 3 dni (!), Zanim uruchomił się kod realokacji sektorów i zamapował niektóre wolne sektory na złym obszarze dysku ... Ale nie mogę powiedzieć, że kiedykolwiek to widziałem.

Czy ktoś jeszcze widział takie zachowanie? Jeśli tak, jakie były twoje wrażenia z jazdy? Czy to się powtórzyło? Czy dysk ostatecznie całkowicie zawiódł? A może była to niewyjaśniona usterka, która pozostała niewyjaśniona?

W moim przypadku mam już dysk zamienny (uzyskany w ramach gwarancji), więc prawdopodobnie i tak po prostu go wymienię. Ale chciałbym wiedzieć, czy jakoś źle to zdiagnozowałem. Jeśli to pomaga, mam pełne wyjście „smartctl -a” od momentu wystąpienia problemu. Jest tylko trochę długi, więc nie opublikowałem go tutaj.

Jeśli jeden konkretny region fizyczny powierzchni dysku ulegnie uszkodzeniu, do momentu pomyślnego odwzorowania tych sektorów pojawią się nieodkryte błędy odczytu podczas próby odczytu danych zapisanych w tym obszarze. Dysk wie, że sektory są uszkodzone (po nieudanym dostępie do sektorów), ale nie może ponownie mapować sektorów, ponieważ już zawierają dane. Jeśli sformatujesz dysk lub nadpiszesz „złe” sektory, dysk będzie miał możliwość mapowania złych sektorów.

Po zmapowaniu uszkodzonych sektorów i tak długo, jak więcej powierzchni dysku nie ulegnie awarii, jesteś w dobrej formie.

Nie wiem wystarczająco dużo o modelach awarii napędów obecnych napędów, aby wiedzieć, czy istnieje duża korelacja między uszkodzeniem jednej części powierzchni nośnika a problemem rozprzestrzeniania się lub ponownego wystąpienia problemu. Jeśli nie ma korelacji, to kiedy złe sektory zostaną zmapowane, jesteś w dobrej formie. Jeśli nie jest korelacja, to jest to początek końca dla napędu.

Większość współczesnych napędów „usunie” zepsuty blok. Napęd ma pulę zapasowych bloków, a oprogramowanie układowe wykorzystuje je do zastąpienia wszystkich bloków, o których wiadomo, że są złe. Napęd nie może wykonać tego ponownego mapowania, jeśli nie może odczytać bloku, ponieważ nie może dostarczyć poprawnych danych. Zwraca tylko „błąd odczytu”. OZNACZA blok jako zły, więc jeśli blok kiedykolwiek zostanie poprawnie odczytany, wówczas blok zostanie wyodrębniony, a prawidłowe dane zapisane w bloku zastępującym. Jeśli system operacyjny kiedykolwiek ZAPISUJE blok, który znajduje się w stanie „oczekującym na wyjście wektorowe”, wówczas blok jest usuwany wektorem, a dane zapisywane w bloku zastępującym.

Raid oprogramowania Linux, po otrzymaniu błędu odczytu z urządzenia, pobierze prawidłowe dane z innych elementów tablicy, a następnie spróbuje ponownie ZAPISOWAĆ zły blok. Tak więc, jeśli zapis działa poprawnie, to dane są bezpieczne, jeśli nie, napęd po prostu robi powyższe, wektory bloku, a następnie wykonuje zapis. Tak więc napęd za pomocą systemu rajdowego właśnie się naprawił!

Zakładając, że takie zdarzenia są dość rzadkie, prawdopodobnie kontynuowanie ich jest bezpieczne. Jeśli używanych jest zbyt wiele bloków zamiennych, napęd może mieć problem. Istnieje ograniczenie liczby zastępczych bloków, które można wymienić na zastępcze, i jest to funkcja napędu.

Tak, widziałem to również w bardzo podobnych okolicznościach. W moim przypadku był to „zielony” dysk „Green” Western Digital 1 TB „WD” (WD10EARS), który zrobił na mnie ten wyczyn. Current_Pending_SectorSurowa wartość SMART zmieniła się z zera na 6, a następnie na 8, zachęcając demona monitorowania SMART do wysyłania mi złych wiadomości e-mail.

mdadm --failZedytowałem --removedysk z tablicy i wykonałem nieniszczącą przepustkę badblocks, i tak, było najwyraźniej ponad 2 tuziny złych bloków. Kiedy dzień później przyjechał dysk zastępczy, naprawiłem tablicę i życie trwało dalej.

Niedługo potem, z czystej nudy, przeszedłem badblocksdo „nieudanej” jazdy, aby sprawdzić, czy się pogorszyła. Przeciwnie, napęd sam się „naprawił”: zero złych bloków! Kręcąc głową, wytarłem ją i odłożyłem na bok, aby poddać recyklingowi lub przekazać.

Lekcja: Nie używaj dysków klasy konsumenckiej na serwerach, chyba że jesteś gotów i jesteś w stanie pogodzić się z wszelkimi dziwnościami i zawodnością. Konsekwencją: nie taniej na komponentach serwera, ponieważ ostatecznie i tak za nie zapłacisz, w dodatkowym czasie i w pogarszaniu się.

Powszechną praktyką w środowiskach serwerowych jest odrzucanie dysków, które kiedykolwiek wykazywały takie błędy, naprawione lub nie. Ciężkie błędy sektorowe mogą być oznaką fizycznego uszkodzenia powierzchni nośnika - a jeśli zarysujesz powierzchnię, zwykle albo przesuniesz materiał na boki rysy i uzyskasz zadziory wyższe niż płaszczyzna takiej powierzchni - lub ścierny pył (szkło! ). Oba są raczej szkodliwe dla systemu mechanicznego, który polega na bardzo cienkiej poduszce powietrznej między dwiema powierzchniami, założonej jako idealnie gładka ... dlatego średnie błędy, gdy zaczynają osiągać określoną liczbę, zwykle mnoży się raczej szybciej.