Come interpretare questi dati smartctl (smartmon)

Abbiamo un server Linux che è stato utilizzato pesantemente per 3 anni. Stiamo eseguendo un numero di server virtualizzati su di esso, alcuni che non sono stati ben educati, e per un tempo significativo la capacità di io del server è stata superata portando a un cattivo interesse. Dispone di 4 unità Barracuda sata da 500 GB collegate a un controller raid 3com. 1 Drive ha il sistema operativo e gli altri 3 sono setup raid-5.

Ora abbiamo un dibattito sulla condizione delle unità e se stanno attivamente fallendo.

Ecco una parte dell'output per 1 dei 4 dischi. Tutti hanno statistiche relativamente simili:

Numero di revisione della struttura dati SMART Attributes: 10
Attributi SMART specifici del fornitore con soglie:
ID # ATTRIBUTE_NAME FLAG VALUE PEGGIORE TIPO SUCCESSO AGGIORNATO QUANDO_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail Always - 169074425
  3 Spin_Up_Time 0x0003 095 092 000 Pre-fail Sempre - 0
  4 Start_Stop_Count 0x0032 100 100 020 Old_age Sempre - 26
  5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Sempre - 0
  7 Seek_Error_Rate 0x000f 077 060 030 Pre-fail Always - 200009354607
  9 Power_On_Hours 0x0032 069 069 000 Old_age Always - 27856
 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Sempre - 1
 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Sempre - 26
184 Unknown_Attribute 0x0032 100 100 099 Old_age Sempre - 0
187 Segnalato_ Non corretto 0x0032 100 100 000 Old_age Sempre - 0
188 Unknown_Attribute 0x0032 100 100 000 Old_age Sempre - 1
189 High_Fly_Writes 0x003a 100 100 000 Old_age Sempre - 0
190 Airflow_Temperature_Cel 0x0022 071 060 045 Old_age Always - 29 (Durata min / max 26/37)
194 Temperatura_Celsius 0x0022 029 040 000 Old_age Sempre - 29 (0 21 0 0)
195 Hardware_ECC_Ricuperato 0x001a 046 033 000 Old_age Always - 169074425
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Sempre - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0

Versione registro errori SMART: 1
Nessun errore registrato

La mia interpretazione di questo è che non abbiamo avuto settori danneggiati o altre indicazioni del fatto che uno dei drive non funziona correttamente.

Tuttavia, Raw_Read_Error_Rate e Seek_Error_Rate elevati vengono indicati come indicazioni che le unità stanno morendo.

Nella mia esperienza, Seagates ha numeri strani per quei due attributi SMART. Quando diagnostico un Seagate tendo a ignorarli e osservo più da vicino altri campi come il conteggio dei settori riallocato. Naturalmente, in caso di dubbio, sostituire l'unità, ma anche i nuovissimi Seagates avranno numeri elevati per tali attributi.

Per i dischi Seagate (e forse anche quelli vecchi di WD), Seek_Error_Rate e Raw_Read_Error_Rate sono numeri a 48 bit, dove i 16 bit più significativi sono un conteggio errori e i 32 bit bassi sono un numero di operazioni.

% python
>>> 200009354607 & 0xFFFFFFFF
2440858991
>>> (200009354607 & 0xFFFF00000000) >> 32
46

Quindi il tuo disco ha eseguito 2440858991 ricerche, di cui 46 fallite. La mia esperienza con le unità Seagate è che tendono a fallire quando il numero di errori supera 1000. YMMV.

Il "tasso di errore di ricerca" e il "tasso di errore di lettura non elaborata" RAW_VALUES sono praticamente insignificanti per chiunque, tranne il supporto di Seagate. Come altri hanno sottolineato, i valori non elaborati di parametri come "conteggio settori riallocato" o voci nel registro degli errori dell'unità hanno maggiori probabilità di indicare una maggiore probabilità di errore.

Ma puoi dare un'occhiata ai dati interpretati nelle colonne VALUE, WORST e THRESH che devono essere letti come indicatori:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH
  7 Seek_Error_Rate         0x000f   077   060   030

Ciò significa che il tasso di errore di ricerca è attualmente considerato "77% buono" e segnalato da SMART come un problema quando raggiunge "30% buono". Una volta era stato basso come "60% buono", ma da allora si è magicamente ripreso. Si noti che i valori interpretati vengono calcolati internamente dalla logica SMART dell'unità e il calcolo esatto può o non può essere pubblicato dal produttore e in genere non può essere modificato dall'utente.

Personalmente, considero un'unità che contiene le voci del registro degli errori come "non riuscita" e chiedo una sostituzione non appena si verificano. Tutto sommato, i dati SMART si sono rivelati un indicatore piuttosto debole per la previsione dei guasti, come ha scoperto un documento di ricerca pubblicato da Google .

Ho capito che questa discussione è un po 'vecchia, ma voglio aggiungere i miei 2 centesimi. Ho trovato che le informazioni intelligenti sono piuttosto un buon indicatore di pre-fail. Quando viene raggiunta una soglia intelligente, sostituire l'unità. Ecco a cosa servono quelle soglie.

La maggior parte delle volte inizierai a vedere settori danneggiati. Questo è un segno sicuro che l'unità sta iniziando a non funzionare. SMART mi ha salvato molte volte. Uso il software RAID 1 ed è molto utile poiché sostituisci semplicemente l'unità guasta e ricostruisci l'array.

Eseguo anche autotest brevi e lunghi settimanalmente.

smartctl -t short /dev/sda
smartctl -t long /dev/sda 

Oppure aggiungilo /etc/smartd.conf e invialo via e-mail in caso di errori

/dev/sda -s L/../../3/22 -I 194 -m someemail@somedomain
/dev/sdb -s L/../../7/22 -I 194 -m someemail@somedomain

Assicurati di installare logwatch e reindirizzare root a un indirizzo e-mail e controlla le e-mail quotidiane da logwatch. Le bandiere scattate SMARTD appariranno lì, ma non è di aiuto se nessuno lo monitora regolarmente.

Sì, quei campi sembrano cattivi ma non mi fido (più) delle informazioni riportate da smart (la mia macchina di prova ha un disco che dovrebbe essere morto molto tempo fa se leggi i dati con smartctrl) Il fatto è che hai segnalato alto iowait e le unità hanno 3 anni. Questo dovrebbe bastare per cambiare le unità.

Mi dispiace impegnare negromanzia su questo post, ma nella mia esperienza, i campi "Raw Read Error Rate" e "Hardware ECC Recovered" per un'unità Seagate andranno letteralmente dappertutto e aumenteranno costantemente nell'intervallo di trilioni in quel punto tornerò indietro a zero per continuare nuovamente il processo. Ho un Seagate ST9750420AS che ha avuto quel problema fin dal primo giorno e funziona ancora alla grande anche dopo parecchi anni e oltre 3500 ore di utilizzo.

Penso che quei campi possano essere tranquillamente ignorati se ne stai eseguendo uno nel tuo caso. Assicurati solo che i due campi riportino lo stesso numero e siano costantemente sincronizzati. Se non sono ... beh ... Questo potrebbe significare un problema.

Per automatizzare i calcoli di questa risposta , utilizzare il calcolatore javascript online:

https://yksi.ml/

Questo ti dirà:

• Numero totale di operazioni
• Numero di operazioni fallite

Il calcolatore è valido per Seagate:

• Cerca tasso di errore
• Tasso di errore di lettura non elaborato
• Hardware ECC recuperato

Per ulteriori letture sul calcolo dei valori normalizzati (tra 0 e 100 valori), consultare questo articolo .