Disco rigido leggere errori che ... si fermano?

La mia storia inizia abbastanza semplicemente. Ho un server leggero, che esegue Arch Linux, che memorizza la maggior parte dei suoi dati su un RAID-1 composto da due unità SATA. Funzionò senza problemi per circa 4 mesi. Poi, improvvisamente, ho iniziato a ricevere errori di lettura su una delle unità. Sempre, i messaggi assomigliavano molto a questi:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

Ogni errore lamentava un diverso numero di settore ed era accompagnato da un ritardo di alcuni secondi per l'utente (me) che accedeva al disco.

Ho controllato l'output smartctl e ho visto il seguente output (parti irrilevanti tagliate):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

Guardando indietro nei registri, ho scoperto che gli errori si erano effettivamente verificati per alcuni giorni, principalmente durante i backup, ma anche spesso durante un uso molto leggero (il che significa che ogni 5 volte ho provato a salvare un file di testo). Ho concluso che il mio disco stava morendo, che il RAID-1 lo stava gestendo in modo appropriato e che era tempo di ordinare un disco sostitutivo. Ho ordinato un nuovo disco.

Con mia grande sorpresa, il giorno dopo, gli errori ... si sono fermati. Non avevo fatto nulla per risolverli. Non avevo riavviato, non avevo portato l'unità offline, niente. Ma gli errori si sono appena fermati.

A quel punto, curioso di vedere se i settori danneggiati fossero solo in porzioni inattive del disco ora, ho tolto il disco dal RAID, rimesso nel RAID e gli ho permesso di completare la successiva risincronizzazione completa. La risincronizzazione è stata completata senza errori, 9 ore dopo (i dischi da 2 TB impiegano un po 'di tempo).

Inoltre, l'output di smartctl è leggermente cambiato, come segue:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

Quindi, la parte di questo che mi sta stranendo è, ovviamente, "Da quando i dischi cattivi si riparano da soli?"

Suppongo sia possibile che un'area molto piccola dell'unità si sia guastata spontaneamente e che l'unità abbia semplicemente impiegato 3 giorni (!) Prima che il suo codice di riallocazione settoriale entrasse in funzione e mappasse alcuni settori di riserva su un'area difettosa del disco ... Ma non posso dire di aver mai visto accadere.

Qualcun altro ha visto questo tipo di comportamento? In tal caso, quale è stata la tua esperienza con l'unità in seguito? È successo di nuovo? Il disco alla fine si è guastato completamente? O era solo un problema tecnico inspiegabile che è rimasto inspiegabile?

Nel mio caso, ho già l'unità sostitutiva (ottenuta in garanzia), quindi probabilmente sostituirò comunque l'unità. Ma mi piacerebbe sapere se ho erroneamente diagnosticato questo in qualche modo. Se aiuta, ho l'output completo di "smartctl -a" da quando si è verificato il problema. È solo un po 'lungo, quindi non l'ho pubblicato qui.

Se una specifica regione fisica della superficie dell'unità si guasta, fino a quando questi settori non possono essere mappati correttamente, otterrai errori di lettura non recuperati quando provi a leggere qualsiasi dato che è stato scritto in quell'area. L'unità sa che i settori sono danneggiati (dopo gli errori di accesso ai settori) ma non possono rimappare i settori perché contengono già dati. Se si formatta l'unità o si sovrascrive i settori "danneggiati", l'unità avrà l'opportunità di mappare i settori danneggiati.

Una volta tracciati i settori danneggiati e finché non viene a mancare una parte maggiore della superficie del disco, sei in buona forma.

Non so abbastanza sui modelli di guasto delle unità attuali per sapere se c'è molta correlazione tra una parte della superficie del supporto che va male e il problema si sta diffondendo o ripetendo. Se non c'è alcuna correlazione, una volta che i settori danneggiati vengono mappati, sei in buona forma. Se v'è una correlazione, allora questo è l'inizio della fine per l'unità.

La maggior parte delle unità moderne "disegna" un blocco che è andato male. L'unità ha un pool di blocchi di riserva e il firmware li utilizza per sostituire tutti i blocchi noti per essere danneggiati. L'unità non può eseguire questa nuova mappatura quando non riesce a LEGGERE un blocco perché non può fornire i dati corretti. Restituisce semplicemente "errore di lettura". Contrassegna il blocco come errato, quindi se il blocco viene letto correttamente, il blocco viene eliminato e i dati corretti vengono scritti nel blocco sostitutivo. Se il sistema operativo SCRIVI mai su un blocco che si trova in uno stato "vector out pending", il blocco viene rimosso e i dati scritti nel blocco sostitutivo.

Il raid del software Linux, ottenendo un errore di lettura da un dispositivo, otterrà i dati corretti da altri elementi dell'array e quindi proverà a SCRIVERE di nuovo il blocco danneggiato. Quindi, se la scrittura funziona bene, i dati sono al sicuro, in caso contrario, l'unità fa solo quanto sopra, vettori il blocco e quindi esegue la scrittura. Quindi, l'unità ha, con l'aiuto del sistema raid, appena riparato!

Supponendo che tali eventi siano ragionevolmente rari, è probabilmente sicuro continuare. Se vengono utilizzati troppi blocchi sostitutivi, l'unità potrebbe avere un problema. Esiste un limite al numero di blocchi sostitutivi che possono essere convertiti in blocchi di riserva e questa è una funzione dell'unità.

Sì, ho visto anche questo, e in circostanze molto simili. Nel mio caso, è stato un disco Western Green da 1 TB "Green" di livello consumer (WD10EARS) a farmi quella prodezza. Il Current_Pending_Sectorvalore grezzo di SMART è passato da zero a 6, quindi a 8, spingendo il demone di monitoraggio SMART a inviarmi alcune e-mail minacciose.

Ho mdadm --faileditato --removeil disco dall'array e ho passato un passaggio non distruttivo badblockssu di esso, e sì, apparentemente c'erano apparentemente più di 2 dozzine di blocchi danneggiati. Quando il disco sostitutivo è arrivato circa un giorno dopo, ho riparato l'array e la vita è andata avanti.

Poco dopo, per pura noia, ripeto badblocksil drive "fallito" per vedere se fosse peggiorato. Al contrario, l'unità si era completamente "riparata" da sola: zero blocchi danneggiati! Scuotendo la testa, l'ho pulito e l'ho messo da parte per essere riciclato o donato.

La lezione: non utilizzare unità di livello consumer nei server, a meno che tu non sia disposto e in grado di sopportare qualsiasi tipo di stranezza e inaffidabilità. Corollario: non risparmiare sui componenti del server, perché alla fine finirai comunque per pagarli, in termini di tempo extra e aggravamento.

È pratica comune negli ambienti server scartare le unità che hanno mai mostrato tali errori, riparati o meno. Gli errori duri del settore possono essere un segno di danni fisici alla superficie del supporto - e se si graffia una superficie di solito si sposta il materiale ai lati del graffio e si ottiene una sbavatura più alta del piano di tale superficie - o polvere abrasiva (vetro! ). Entrambi tendono ad essere piuttosto dannosi per un sistema meccanico che si basa su un cuscino d'aria molto sottile tra due superfici assunto perfettamente liscio ... ecco perché gli errori medi quando iniziano a raggiungere un certo conteggio tendono a moltiplicarsi piuttosto più rapidamente.