Quote:
Originariamente inviato da giovanni69
E questi interventi ECC cumulativi, come controllare se hanno fatto il loro dovere oppure comunque hanno comportato perdita di dati?
Semplicemente è tutto a posto perchè gli ECC falliti sono 0?
|
Secondo me è tutto a posto e il parametro S.M.A.R.T. “ECC corretti cumulativi” indica le correzioni degli errori dei dati fatti tramite ECC mentre il parametro “ECC falliti” le volte in cui l’ECC ha fallito. Quindi qui l’SSD ti sta dicendo “ho corretto 587.312 bit senza mai fallire una volta”. Devo dire, però, che questa è la prima volta che vedo questi parametri nello S.M.A.R.T. di un SSD, quindi non son sicuro al 100% di quello che dico (anche se a logica è così).
Comunque, per dare un po’ di contesto in più, l’ECC è il codice di correzione degli errori di un SSD e può essere o BCH o LDPC. L’ECC è quindi necessario per rilevare e correggere gli errori. BCH è più vecchio e meno potente dell’LDPC ed è infatti in disuso.
Quando un SSD scrive una pagina la divide in più chunk di memoria. Per ogni chunk l’ECC genera un codeword, ossia dei bit in più ai bit “normali” che sono ridondanti e che servono per la rivelazione e correzione degli errori. Quindi il chunk di memoria più i bit ridondanti si chiama “codeword”. Più è grande il codeword più “forte” sarà l’ECC dal momento che la forza di protezione di un ECC è data dal coding rate, ossia il rapporto tra la dimensione dei chunk e la dimensione dei codeword. Ora la dimensione tipica del codeword LDPC nei nuovi controller è di 4kB, una volta era 2kB e 1kB. Al di sotto del kB, se ricordo bene, c’era soltanto il BCH.
Coding rate e la lunghezza del codeword formano insieme la capacità di correzione degli errori di un ECC, ossia il numero massimo di errori di bit grezzi (RBER in inglese) che l’ECC può correggere. Quando il RBER è troppo alto l’ECC fallisce.