Oprogramowanie układowe napędu uruchamia testy.
Szczegóły testów można przeczytać np. Na stronie www.t13.org/Documents/UploadedDocuments/technical/e01137r0.pdf, który podsumowuje elementy krótkich i długich testów w ten sposób:
segment elektryczny, w którym napęd testuje własną elektronikę. Konkretne testy w tym segmencie są specyficzne dla dostawcy, ale jako przykłady: ten segment może obejmować takie testy, jak test pamięci RAM bufora, test obwodów odczytu / zapisu i / lub test elementów głowicy odczytu / zapisu.
segment poszukiwania / serwonapędów, w którym przemiennik sprawdza zdolność do znajdowania i serwomechanizmu na ścieżkach danych. Konkretna metodologia zastosowana w tym teście jest również specyficzna dla dostawcy.
segment skanowania odczytu / weryfikacji, w którym napęd wykonuje skanowanie odczytu pewnej części powierzchni dysku. Ilość i lokalizacja skanowanej powierzchni zależą od ograniczenia czasowego ukończenia i zależą od dostawcy.
Kryteria rozszerzonego autotestu są takie same jak krótki autotest z dwoma wyjątkami: segment (3) przedłużonego autotestu to skanowanie odczytu / weryfikacji całego obszaru danych użytkownika, i nie ma maksymalny czas na przeprowadzenie testu przez napęd.
Bezpieczne jest przeprowadzanie testów nieniszczących podczas działania systemu operacyjnego, choć możliwy jest pewien wpływ na wydajność. Jak smartctl
mówi strona podręcznika dla obu -t short
i -t long
,
Ta komenda może być wydana podczas normalnej pracy systemu (chyba że jest uruchomiona w trybie niewoli)
Jeśli wywołasz tryb przechwytywania za pomocą -C
, smartctl
zakłada się, że dysk może być zajęty do niedostępności. Nie należy tego robić na dysku używanym przez system operacyjny.
Jak sugeruje również strona podręcznika, testy offline (co po prostu oznacza okresowe testy w tle) nie są niezawodne i nigdy oficjalnie nie stały się częścią specyfikacji ATA. Zamiast tego używam mojego z crona; w ten sposób wiem, kiedy powinny się zdarzyć, i mogę to zatrzymać, jeśli zajdzie taka potrzeba.
- Wyniki można zobaczyć w danych
smartctl
wyjściowych. Oto test z uruchomionym testem:
[root @ risby images] # smartctl -a / dev / sdb
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.1.6-201.fc22.x86_64] (kompilacja lokalna)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org
[...]
SMART Numer wersji dziennika testu autotestu 1
Num Test_Description Status Pozostały czas życia (godziny) LBA_f_pierwszy błąd
# 1 Rozszerzone offline Ukończone bez błędu 00% 20567 -
# 2 Rozszerzone offline Ukończone bez błędu 00% 486 -
INTELIGENTNY Selektywny test struktury danych dziennika numer wersji 0
Uwaga: numer wersji nie 1 oznacza, że nigdy nie przeprowadzono selektywnego autotestu
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Self_test_in_progress [pozostało 90%] (0-65535)
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Zanotuj dwa poprzednie zakończone testy (odpowiednio przy 486 i 20567 godzinach włączenia) i bieżący trwający (10% ukończony).
MadHatter obsługuje Monikę
źródło
Implementacje SMART są zależne od producenta, czasem dość obszerne logi są dostępne za pomocą
smart -a
komend. Oto, co otrzymuję na jednym z moich samoszyfrujących dysków Hitachi :Ten biały papier rzuca nieco światła na kody błędów pojawiające się w logu. Typowe skróty błędów to:
W moim przypadku błąd IDNF (nie znaleziono identyfikatora) można przypisać incydentowi, gdy dysk został podłączony za pomocą adaptera USB-SATA i okazał się zbyt niski, co uniemożliwiło prawidłowe wyszukiwanie.
źródło