Test SMART nigdy się nie kończy

Podczas uruchamiania testów SMART przy użyciu smartmontools, NIGDY nie kończą się. Zawsze dostaję „Przerwany (reset hosta)” na różnych systemach i dyskach, w tym Debian w x86 i ARM, OS X na x64, z dyskami zewnętrznymi i wewnętrznymi. Nawet gdy działa w trybie przechwytywania z pustymi dyskami (zerowanymi za pomocą dd).

Co ja robię źle?

Gdy dysk nie obsługuje żadnej aktywności wejścia / wyjścia podczas testu, może przejść do trybu gotowości, co podnosi Interrupted (host reset)stan. Spróbuj czytać z dysku w odpowiednich odstępach czasu:

while true; do dd if=/dev/disk1 of=/dev/null count=1; sleep 60; done

(zamień /dev/disk1na odpowiednie urządzenie; odczytuje jeden sektor z tego urządzenia co 60 sekund, aż uderzysz ctrl-c)

Pomogło to w moim środowisku: OS X 10.6.8, napęd WD Elements USB, sterownik SAT-SMART 0.8.

Test w niewoli powinien teoretycznie utrzymywać dysk w trybie online. Jednak wysłanie polecenia sprzętowego smartctlmoże przekroczyć limit czasu przed zakończeniem testu, powodując zresetowanie łącza przez jądro i kończąc w takiej samej sytuacji jak powyżej ( błąd nr 303 ).

Zobacz ten wątek na liście mailingowej wsparcia smartmontools, aby uzyskać więcej informacji. Doceniam Christiana Franke za podany tutaj wgląd.

Wypróbowałem rozwiązanie od Tobu, w moim przypadku ciągle znajdowałem zewnętrzny dysk USB w trybie uśpienia, niezależnie od czasu po uruchomieniu testu i przerwaniu go, wydaje się, że dd skończyło się czytaniem z pamięci podręcznej jądra, a pamięć podręczna była wystarczająco duża dla dysku wejść w tryb uśpienia. Zauważyłem, że wywołanie smartctl z prośbą o status zawsze było w stanie „obudzić” dysk. Więc: ta wersja tego samego pomysłu zrobiła dla mnie lewę:

sudo bash -c 'while true; do smartctl -a /dev/sdb > /dev/null; sleep 60; done'

Po 5 godzinach zewnętrzny dysk USB nadal się kręci. Po raz pierwszy mogłem zobaczyć długi test smartctl na dysku zewnętrznym.

Wierzę, że to rozwiązanie ma tę zaletę, że głowice dysków nie są niepotrzebnie przesuwane co minutę. Długi bieg zakończył się prawie dokładnie w przewidywanym czasie (skrypt czuwania nie dodał czasu do biegu)

Wariacją odpowiedzi Ari jest użycie watch, ponieważ smartctlwyjście może być interesujące, aby śledzić status:

sudo watch -d -n 60 smartctl -a /dev/sdx

Spowoduje to automatyczną aktualizację wyniku smartctl -aco 60 sekund, dzięki czemu możesz zobaczyć, ile pozostało czasu autotestu, i wyróżnić zmiany (dzięki czemu łatwiej jest zauważyć, że test rzeczywiście postępuje).

Test w niewoli może nie działać, jeśli zajmuje więcej niż 20 sekund.

Źródło: bilet nr 303 , zatytułowany „W trybie przechwytywania inteligentnego testu, wydłuż limit czasu zgodnie z opisem urządzenia ATA”.