Co robi testowanie SMART i jak działa?

man smartctl stwierdza (zwięzłe):

Pierwsza kategoria o nazwie „online” testowania. Druga kategoria testów nazywa testowanie „offline”. Zwykle dysk zawiesza testowanie w trybie offline podczas dostępu do dysku, a następnie automatycznie wznawia go, gdy w przeciwnym razie dysk byłby bezczynny. Trzecia kategoria testowania (i jedyną kategorią, dla których słowo'testing' jest naprawdę odpowiedni wybór) jest „ja” testowanie.

Włącza lub wyłącza automatyczny test offline SMART, który skanuje dysk co cztery godziny pod kątem wad dysku. To polecenie można wydać podczas normalnej pracy systemu.

Kto uruchamia oprogramowanie wewnętrzne dysku testowego? Co to za testy - czy oprogramowanie układowe odczytuje / zapisuje na dysk - co dokładnie się dzieje? Czy bezpiecznie jest wywołać testowanie w systemie operacyjnym (Linux), czy można zaplanować test na później - jak to się dzieje - po ponownym uruchomieniu systemu operacyjnego po znaku zachęty BIOS („test offline”)? Gdzie są wyświetlane wyniki - dzienniki SMART?

1. Oprogramowanie układowe napędu uruchamia testy.

2. 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:

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

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

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

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

3. Bezpieczne jest przeprowadzanie testów nieniszczących podczas działania systemu operacyjnego, choć możliwy jest pewien wpływ na wydajność. Jak smartctlmówi strona podręcznika dla obu -t shorti -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, smartctlzakł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.

4. Wyniki można zobaczyć w danych smartctlwyjś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).

Implementacje SMART są zależne od producenta, czasem dość obszerne logi są dostępne za pomocą smart -akomend. Oto, co otrzymuję na jednym z moich samoszyfrujących dysków Hitachi :

SMART Error Log Version: 1
ATA Error Count: 3

Error 3 occurred at disk power-on lifetime: 2543 hours (105 days + 23 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
10 51 08 00 08 00 00  Error: IDNF at LBA = 0x00000800 = 2048

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
-- -- -- -- -- -- -- --  ----------------  --------------------
60 08 68 00 08 00 40 00      00:00:06.139  READ FPDMA QUEUED
27 00 00 00 00 00 e0 00      00:00:06.126  READ NATIVE MAX ADDRESS EXT
ec 00 00 00 00 00 a0 00      00:00:06.125  IDENTIFY DEVICE
ef 03 46 00 00 00 a0 00      00:00:06.125  SET FEATURES [Set transfer mode]
27 00 00 00 00 00 e0 00      00:00:06.125  READ NATIVE MAX ADDRESS EXT
...

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:

• AMNF - Nie znaleziono znacznika adresu
• TONF - nie znaleziono ścieżki 0
• ABRT - polecenie przerwane
• IDNF - Nie znaleziono identyfikatora sektora
• UNC - Niepoprawne dane
• BBK - Zły znak bloku

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.