Jak odróżnić uszkodzony kabel SATA od uszkodzonego dysku NAS

Zły kabel SATA powoduje błędy transportu, podczas gdy uszkodzony dysk generuje błędy nośnika lub urządzenia. Wiarygodnym testem jest śledzenie, który typ błędu rośnie i gdzie się pojawia.

Nie diagnozuj na podstawie pojedynczego statusu SMART ani jednego rozłączenia. Zapisz numer seryjny dysku, aktualne liczniki, komunikaty jądra, zatokę, kabel i port kontrolera, a następnie zmieniaj po kolei pojedyncze elementy ścieżki. Wzorzec po każdej kontrolowanej zmianie jest bardziej użyteczny niż pierwotna liczba błędów.

Zrób bazowy zapis przed ponownym podłączeniem czegokolwiek

Zapisz numer seryjny, model, zatokę, port kontrolera, atrybuty SMART, dziennik autotestu, dziennik błędów oraz ostatnie komunikaty systemowe dotkniętego dysku przed zmianą kabla. Ponowne podłączenie może zatrzymać objawy, jednocześnie zacierając związek między dyskiem a ścieżką.

Nazwy urządzeń takie jak /dev/sdX mogą się zmieniać po restarcie lub zmianie kabla, dlatego numer seryjny jest stabilną tożsamością. Oznacz czas bazowy i zanotuj surowe wartości liczników, ponieważ niektóre liczniki SMART są kumulatywne i nie zerują się po wymianie kabla.

Wstrzymaj intensywne zapisy, jeśli macierz jest zdegradowana lub błędy rosną. Najpierw zachowaj dowody, potem wykonaj jedną kontrolowaną zmianę; inaczej wymiana kabla, zatoki, złącza zasilania i dysku jednocześnie nie da wiarygodnej diagnozy.

Oddziel błędy transportu od błędów nośnika

Błędy transportu występują podczas przesyłania poleceń lub danych przez ścieżkę SATA, natomiast błędy nośnika pojawiają się, gdy dysk nie może niezawodnie odczytać lub zapisać sektorów. Obie klasy usterek mogą powodować podobne objawy aplikacji, ale wskazują na różny sprzęt.

Model błędów ATA w Linuksie rozróżnia błąd magistrali ATA od błędu nośnika: błędy CRC i transmisji dotyczą ścieżki, natomiast niekorygowalny odczyt zgłaszany po próbach należy do nośnika urządzenia. Timeouty mogą być niejednoznaczne, dlatego wymagają wspierających liczników i kontrolowanych wymian.

Klasyfikuj każdy wpis w dzienniku przed podjęciem działań. Rosnące błędy CRC lub resetów łącza kierują uwagę na kabel, złącze, płytę tylnią, stabilność zasilania lub ścieżkę kontrolera; nieczytelne sektory i nieudane autotesty wskazują na podejrzenie samego dysku.

Obserwuj, czy liczniki CRC i resetów łącza nadal rosną

Niezerowy licznik CRC pokazuje, że wystąpiły błędy interfejsu, ale sama suma historyczna nie dowodzi, że kabel jest obecnie uszkodzony. Kluczowym sygnałem jest, czy surowa wartość rośnie podczas znanego okna testowego.

ICRC rejestruje błąd CRC interfejsu. Ponieważ licznik ten jest przechowywany przez dysk, może być widoczny po wymianie oryginalnego kabla lub hosta, więc porównuj wartości przed i po, zamiast traktować każdą przeszłą wartość jako aktywną usterkę.

Przeprowadź kontrolowany odczyt po ponownym podłączeniu lub wymianie kabla danych i zapisz nową wartość. Jeśli zdarzenia CRC lub resetów łącza ustają, a wskaźniki nośnika pozostają stabilne, przyczyną była ścieżka; jeśli licznik nadal rośnie, kontynuuj izolowanie zatoki, portu i złącza zasilania.

Użyj autotestów, aby sprawdzić awarię dysku

Dysk pozostaje podejrzany, gdy zgłasza nieczytelne sektory, sektory oczekujące, sektory przeniesione, nieudane polecenia niezwiązane z CRC lub autotest zatrzymujący się w powtarzalnym miejscu. Te sygnały dotyczą zdolności urządzenia do dostępu do nośnika.

Autotesty SMART i dzienniki błędów są przydatne, ponieważ zachowują dowody po stronie urządzenia, nie opierając się wyłącznie na warstwie RAID. Dziennik autotestów SMART należy interpretować razem z surowymi atrybutami i dziennikami systemowymi, a nie sprowadzać do pojedynczej linii PASSED.

Nie uruchamiaj testu rozszerzonego, który przeciąży poważnie zdegradowaną macierz lub dysk już zwracający powtarzające się błędy odczytu. Gdy dane są zagrożone, priorytetem jest kopia zapasowa lub obrazowanie, a następnie testowanie izolowanego dysku pod kontrolowanym obciążeniem.

Wymieniaj po jednym elemencie ścieżki na raz

Najbardziej jednoznacznym wskaźnikiem jest, czy usterka podąża za fizycznym dyskiem, czy pozostaje na ścieżce SATA. Zmieniaj tylko jeden element na test: najpierw kabel danych, potem zatokę lub ścieżkę płyty tylnej, a na końcu port kontrolera, jeśli platforma na to pozwala bezpiecznie.

Zachowaj ten sam numer seryjny dysku i obciążenie podczas porównywania nowych błędów. Licznik transportu rosnący tylko w jednej zatoce lub z jednym kablem wskazuje na problem poza dyskiem, natomiast błędy nośnika i nieudane autotesty podążające za numerem seryjnym przez czyste ścieżki wskazują na dysk.

Nigdy nie przestawiaj aktywnych członków RAID bez zapisu mapowania numer seryjny–slot i potwierdzenia, że stos pamięci identyfikuje członków po metadanych, a nie kolejności slotów. Jeśli system nie obsługuje kontrolowanego przemieszczania, najpierw wymień kabel i użyj dzienników do zawężenia pozostałej ścieżki.

Interpretuj timeouty i resetowania jako dowody wspierające

Timeouty poleceń, resetowania łącza SATA i chwilowe znikanie urządzeń mogą wynikać ze słabego kabla, niestabilnego zasilania, problemu kontrolera lub dysku, który przestaje odpowiadać. Są to ważne sygnały, ale nie wskazują jednoznacznie przyczyny.

Ścieżka odzyskiwania ATA może resetować łącze po błędach transmisji lub nieznanych stanach poleceń. Powtarzające się resetowania wraz z rosnącymi błędami CRC wzmacniają hipotezę problemu ścieżki; powtarzające się niekorygowalne sektory lub nieudane autotesty wzmacniają hipotezę problemu nośnika.

Skoreluj każde zdarzenie czasowo z utratami RAID, błędami I/O aplikacji i zmianami SMART. Pojedynczy reset po konserwacji jest mniej przekonujący niż powtarzający się wzorzec pojawiający się przy tym samym kablu, zatoce lub numerze seryjnym dysku.

Wymień komponent, za którym podążają dowody

Wymień kabel lub napraw ścieżkę, gdy nowe błędy CRC i resetów łącza pozostają powiązane z jednym połączeniem, a dysk przechodzi kontrolowane testy nośnika w innych miejscach. Wymień lub wycofaj dysk, gdy błędy po stronie urządzenia podążają za jego numerem seryjnym przez znane, dobre ścieżki.

Przypadki niejednoznaczne nie powinny być wymuszane na binarną odpowiedź. Uszkodzony dysk może współistnieć z marginalnym kablem, a stabilny autotest SMART nie usuwa powtarzających się błędów transportu, które mogą nadal powodować utratę członka RAID.

Po naprawie ustal nową bazę i zweryfikuj, że liczniki przestają rosnąć podczas normalnego obciążenia, skanowania lub sprawdzania spójności oraz okresu monitoringu. Zgłoś eskalację lub wykonaj obraz dysku, gdy błędy się utrzymują, dane są nieczytelne lub macierz nie ma już nadmiarowości.