Soluzione 1:
Per i dischi Seagate (e forse anche alcuni 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 degli 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 guastarsi quando il numero di errori supera i 1000. YMMV.
Soluzione 2:
Il "tasso di errore di ricerca" e il "tasso di errore di lettura non elaborato" RAW_VALUES sono praticamente privi di significato per chiunque tranne il supporto di Seagate. Come altri hanno sottolineato, è più probabile che i valori grezzi di parametri come "conteggio dei settori riallocati" o le voci nel registro degli errori dell'unità indichino una maggiore probabilità di errore.
Ma puoi dare un'occhiata ai dati interpretati nelle colonne VALUE, WORST e THRESH che devono essere lette come indicatori:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH
7 Seek_Error_Rate 0x000f 077 060 030
Ciò significa che il tuo tasso di errore di ricerca è attualmente considerato "buono al 77%" e viene segnalato come un problema da SMART quando raggiunge il "buono al 30%". Una volta era stato "buono al 60%", ma da allora si è magicamente ripreso. Tieni presente che i valori interpretati vengono calcolati internamente dalla logica SMART dell'unità e il calcolo esatto può o meno essere pubblicato dal produttore e in genere non può essere modificato dall'utente.
Personalmente, considero un'unità contenente voci del registro degli errori come "fallita" e chiedo una sostituzione non appena si verificano. Ma 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.
Soluzione 3:
Nella mia esperienza, Seagates ha numeri strani per questi due attributi SMART. Durante la diagnosi di un Seagate tendo a ignorarli e a guardare più da vicino altri campi come il conteggio dei settori riallocati. Ovviamente, in caso di dubbio, sostituisci l'unità, ma anche i Seagate nuovi di zecca avranno numeri elevati per questi attributi.
Soluzione 4:
Mi sono reso conto che questa discussione è un po 'vecchia ma voglio aggiungere i miei 2 centesimi. Ho scoperto che le informazioni intelligenti sono un buon indicatore di pre-fallimento. Quando si attiva una soglia intelligente, sostituire l'unità. Ecco a cosa servono queste soglie.
La stragrande maggioranza delle volte inizierai a vedere settori danneggiati. Questo è un segno sicuro che l'unità sta iniziando a fallire. SMART mi ha salvato molte volte. Io uso il software RAID 1 ed è molto utile poiché è sufficiente sostituire l'unità guasta e ricostruire l'array.
Eseguo anche autotest brevi e lunghi settimanali.
smartctl -t short /dev/sda
smartctl -t long /dev/sda
Oppure aggiungilo /etc/smartd.conf e ricevilo via email se ci sono errori
/dev/sda -s L/../../3/22 -I 194 -m [email protected]
/dev/sdb -s L/../../7/22 -I 194 -m [email protected]
Assicurati di installare logwatch e reindirizzare root a un indirizzo e-mail e controllare le e-mail giornaliere da logwatch. I flag attivati da SMARTD verranno visualizzati lì, ma non è di alcun aiuto se nessuno lo sta monitorando regolarmente.
Soluzione 5:
Mi dispiace commettere necromanzia 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 incrementano costantemente nell'intervallo di trilioni, a quel punto torneranno indietro a zero per continuare di nuovo il processo. Ho un Seagate ST9750420AS che ha avuto questo problema sin 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 lo sono... beh... Questo in realtà potrebbe significare un problema.