Test SMART nigdy się nie kończy

17

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?

hard-drive smart maintenance

— bot47
źródło

Nie robisz nic złego. To sprzęt, który nie działa

— Ramhound

Czy to w ogóle ma działać?

— bot47

Tak, powinno działać

— Ramhound

@MaxRied, czy mówisz, że wypróbowałeś to na wielu różnych komputerach z logami różnych dysków i wciąż nie widziałeś ukończenia, nawet dla dysków, o których wiesz, że są zdrowe od innego narzędzia analizy SMART?

— Frank Thomas

@FrankThomas Tak.

— bot47

14

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.

— sve.g
źródło

Inne możliwe przerwy ( serverfault.com/a/584055 ): zły kabel może spowodować przekroczenie limitu czasu, a jądro uruchomi reset. Nie jestem pewien, czy konieczne jest zatrzymanie smartd. Przekroczenia czasu i przerwy pojawią się w dmesg / kern.log / journalctl -fk.

— Tobu,

Wow, to szalone! Potwierdzenie - po upuszczeniu HGST HDN726060ALE610 z lustra zpool, utknął na poziomie 10% przez 36 godzin (skończy się szybciej bez innej aktywności, PRAWDA?). Pięć minut tych drobnych odczytów dd zakończyło się. Sceptycyzm odrzucony.

— Bill McGonigle,

Czy /dev/disk1ma to być urządzenie lub partycja, tj. Jak /dev/sdalub /dev/sda1?

— Merchako,

@Merchako To jest związane z Mac OS tam, gdzie tak naprawdę jest.

— bot47,

5

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)

— Ari
źródło

3

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).

— GreatEmerald
źródło

+1, nigdy watchwcześniej nie widziane .

— Hashim,

1

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”.

— Siergiej V.
źródło