Dlaczego błędy scrubowania NAS występują na jednym porcie kontrolera w przypadku różnych dysków?

Błędy skanowania, które podążają za jednym portem kontrolera przy różnych dyskach, zwykle wskazują na wspólną ścieżkę, a nie na nośniki danych dysków.

Skanowanie odczytuje szeroki zestaw bloków i może ujawnić usterki, do których zwykły codzienny dostęp nigdy nie dociera. Jeśli różne, sprawne dyski generują błędy wyłącznie po podłączeniu przez ten sam port, wspólne elementy obejmują kanał kontrolera, złącze, kabel, linię backplane, trasę ekspandera, tor zasilania, oprogramowanie układowe oraz chłodzenie w obrębie tej ścieżki. Diagnoza musi potwierdzić, że błąd podąża za portem, przy jednoczesnym zachowaniu tożsamości dysku, znaczników czasu i typu błędu.

Potwierdź, że błąd podąża za portem, a nie nazwą dysku

Zapisz numery seryjne dysków, stabilne identyfikatory urządzeń, port kontrolera lub PHY HBA, kabel, zatokę, członka puli oraz liczniki odczytów, zapisów i sum kontrolnych przed rozpoczęciem kolejnego skanowania. Nie polegaj wyłącznie na zmieniających się nazwach /dev/sdX.

Przewodnik TrueNAS dotyczący rozwiązywania problemów z dyskiem podkreśla konieczność zebrania danych o puli i SMART przed wyzerowaniem błędów lub wymianą urządzenia.

Po zamianie wykonanej przy wyłączonym zasilaniu sprawdź, czy błąd podąża za dyskiem, zatoką, kablem czy portem kontrolera. Zmieniaj tylko jeden element podczas każdego testu, aby wynik pozostał możliwy do zinterpretowania.

Oddziel błędy sum kontrolnych skanowania od błędów odczytu i zapisu dysku

Zapisz pełny wynik skanowania oraz liczniki dla poszczególnych urządzeń. Niezgodność sumy kontrolnej, przekroczenie czasu wykonania polecenia, nieczytelny sektor i nieudany zapis oznaczają różne warstwy awarii.

Firma Oracle wyjaśnia, że skanowanie ZFS weryfikuje sumy kontrolne aktywnych danych, natomiast stan puli osobno raportuje błędy odczytu, zapisu i sum kontrolnych dla każdego urządzenia.

Jeśli liczba błędów sum kontrolnych rośnie bez błędów nośnika i podąża za jedną fizyczną ścieżką, podejrzewaj uszkodzenie danych między pamięcią a dyskiem lub niestabilny transport. Jeśli błędy odczytu podążają za dyskiem między portami, bardziej prawdopodobną przyczyną staje się sam dysk.

Przypisz dysk do dokładnego kontrolera i łącza

Prześledź stabilną ścieżkę dysku przez kontroler hosta, adres PCI, ekspander SAS lub port SATA, obudowę, kabel i zatokę. Zapisz mapowanie przed przenoszeniem sprzętu.

Widok urządzeń lspci identyfikuje kontroler pamięci masowej PCI niezależnie od nazw systemu plików i puli, co pomaga odróżnić awarię jednej ścieżki kontrolera od dysku, któremu po prostu nadano nową nazwę urządzenia.

W przypadku HBA uwzględnij informacje o PHY i ekspanderze, jeśli są dostępne. Dwie przednie zatoki mogą współdzielić jeden kabel mini-SAS lub jedną linię ekspandera, mimo że interfejs użytkownika przedstawia je jako osobne gniazda.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sprawdź resetowania łącza SATA lub SAS podczas skanowania

Monitoruj dziennik jądra od chwili rozpoczęcia skanowania. Szukaj twardych resetów, nieudanych operacji COMRESET, zdarzeń utraty łącza, przekroczeń czasu poleceń, błędów protokołu oraz zmian wynegocjowanej prędkości na dotkniętej ścieżce.

Przewodnik Linux libATA opisuje resetowanie łącza i odzyskiwanie po błędach dla poszczególnych portów, pokazując, dlaczego powtarzające się komunikaty przypisane do jednego portu ATA są mocniejszym dowodem niż ogólne ostrzeżenie dotyczące puli.

Zachowaj pierwszy komunikat transportowy. Późniejsze błędy systemu plików mogą być jedynie konsekwencją utraty komunikacji przez kontroler podczas odczytu.

Porównaj liczniki błędów CRC interfejsu i przekroczeń czasu poleceń

Przechwyć atrybuty i dzienniki SMART każdego dysku przed jednym skanowaniem i po nim. Sprawdź, czy liczniki błędów CRC interfejsu lub przekroczeń czasu poleceń rosną wyłącznie na dotkniętej ścieżce.

Unraid wyjaśnia, że błędy CRC UDMA występują między dyskiem a kontrolerem, zwykle wskazując na kable, złącza, trasowanie lub łącze kontrolera, a nie na uszkodzenie talerzy.

Historyczna suma błędów CRC nie identyfikuje bieżącego komponentu. Zapisz surową wartość, wykonaj jeden ograniczony test i sprawdź wyłącznie, czy wartość wzrosła.

Uruchom testy dysków niezależnie od obciążenia skanowaniem

Uruchamiaj obsługiwane krótkie i rozszerzone testy SMART, gdy pula jest poza tym nieobciążona, a dane są chronione. Unikaj planowania pełnego testu SMART jednocześnie z innym skanowaniem lub odbudową.

Dokumentacja smartctl dla Debiana oddziela wewnętrzne autotesty dysku i dzienniki błędów od weryfikacji systemu plików wykonywanej po stronie hosta.

Dysk, który przechodzi test wewnętrzny, ale generuje błędy wyłącznie na jednym porcie kontrolera, wzmacnia hipotezę dotyczącą ścieżki. Nie dowodzi to jednak, że dysk jest całkowicie sprawny, dlatego po zmianie portu nadal monitoruj sytuację.

Wymień jeden wspólny komponent i powtórz ograniczone skanowanie

Po upewnieniu się, że kopie zapasowe są aktualne, i wyłączeniu serwera przenieś sprawny dysk przez podejrzaną ścieżkę lub wymień jeden kabel, pozostawiając pozostałe zmienne bez zmian. Nie przekładaj jednocześnie wszystkich dysków.

Przewodnik ZimaSpace dotyczący wypadniętego dysku a uszkodzonej zatoki przedstawia analogiczną metodę kontrolowanej zamiany; ten artykuł stosuje tę logikę konkretnie do błędów skanowania, które stale podążają za jednym portem kontrolera.

Zatrzymaj skanowanie i nadaj priorytet ochronie danych, jeśli liczba błędów gwałtownie rośnie, kilka dysków podłączonych do tego samego kontrolera jest resetowanych, pula ulega degradacji lub aplikacje zgłaszają uszkodzone pliki. Problem można uznać za rozwiązany dopiero wtedy, gdy ta sama ścieżka portu wielokrotnie ukończy skanowanie i zwykłe operacje wejścia-wyjścia bez nowych błędów.