Qual è la granularità di un URE del disco rigido (errore di lettura irrecuperabile)?

tl; dr nel caso in cui si verifichi un URE su un hdd, perderò 1 bit, 1 byte o le dimensioni di un settore (512 byte o 4096 byte AF)? e se possibile spiegare perché?

Sfondo: la domanda qui sorge quando un disco rigido ha un problema nella lettura dei dati. Sicuramente un disco può fallire completamente lasciando tutti i suoi dati persi (DISK FAIL), ma il caso di cui mi chiedo qui è che quando si perde solo una piccola parte di esso (URE, un errore di lettura non correggibile).

Anche se ho cercato informazioni su URE, ho scoperto poco per certo. Ciò potrebbe avere la sua causa in quanto ciò che accade internamente nell'unità, ovvero ciò che è nascosto dall'interazione diretta dell'utente come la correzione ECC, è per me difficile da mettere in relazione con ciò a cui accedo come utente: i settori.

Immaginiamo che l'hdd abbia difficoltà a leggere i dati.

In quella situazione, sicuramente questo deve significare che:

• (a) alcuni bit del settore non possono essere letti, o
• (b) tutti i bit possono essere letti, ma non superano un test di checksum (ovviamente si aspettano problemi in un settore 4096 byte non sono solo 8 * 4096 bit, ma alcuni bit / byte aggiuntivi per il controllo / correzione degli errori (es. bit di parità ) (c) ????

Non credo che quando ci troviamo nella situazione in cui si è verificata una combinazione di (a) e (b) e non si può fare una ricostruzione affidabile dei byte del settore 4096, allora è eccessivo presumere che necessariamente tutti siano garpage , in realtà se fossimo a conoscenza della logica di correzione degli errori hdd interale potremmo invece dire "guarda qualcosa non si verifica, e con una buona modifica almeno 1,2,3, n bit / byte dei dati del blocco è" sbagliato " ". Se stessimo salvando in modo ridondante "ciao, ciao ....., ciao" stringhe di byte ASCII in questo settore, potremmo effettivamente avere ancora una discreta successione di "ciao, ciao ...." prima che ci sia un "... Uellohello ... "(ovvero" e "->" U ").

Quindi qual è la granularità di un URE?

AGGIORNAMENTO: c'è stato un commento che ha introdotto l'idea di un settore danneggiato (e ha suggerito che ciò riflette la granularità di un evento URE. Non è assurdo, suggerirlo e forse può essere usato per rispondere alla domanda. Eppure ho appena letto un altro domanda su settori in attesa illeggibili (qui /unix/1869/how-do-i-make-my-disk-unmap-pending-unreadable-sector ) che mi porta a pensare che in alcuni scenari c'è davvero una linea più sfocata tra i dati persi in caso di un URE.

Il codice di correzione dell'errore su un disco rigido è un blocco aggiuntivo di dati associato a ciascun settore hardware. Durante la scrittura, il firmware dell'unità calcola questi dati e li scrive insieme ai dati dell'utente. Durante la lettura il firmware legge l'ECC insieme ai dati e li controlla insieme.

Per un disco rigido tradizionale il settore hardware è di 512 byte. Per un'unità di formato avanzato sono 4K byte (non importa se l'unità presenta settori a 512 byte o 4K byte all'interfaccia, ovvero 512e contro 4kn).

Il risultato del controllo dopo una lettura ha sostanzialmente tre possibili risultati:

• settore è stato letto senza errori. Questo in realtà non è completamente comune sui moderni dischi rigidi; le densità dei bit sono tali da dipendere dal funzionamento dell'ECC.

• settore è stato letto con errori correggibili. Come implicito sopra questo non è raro; è previsto. L'unità restituisce i dati, con la correzione degli errori applicata, all'utente.

• il settore è stato letto ma c'erano troppi "bit sbagliati"; gli errori non possono essere corretti.

In quest'ultimo caso, l'unità non restituisce normalmente alcun contenuto; restituisce solo uno stato che indica l'errore. Questo perché non è possibile sapere quali bit sono sospetti, e tanto meno quali dovrebbero essere i loro valori. Pertanto l'intero settore (bit ECC e tutti) non è affidabile. È impossibile determinare quale parte del settore danneggiato è cattiva, figuriamoci quale dovrebbe essere il suo contenuto. L'ECC è un "gestalt" che viene calcolato su tutto il contenuto del settore e, se non corrisponde, è l'intero settore a non corrispondere.

SpinRite funziona semplicemente provando a leggere più volte il settore danneggiato, utilizzando una funzione di "lettura di manutenzione" che restituisce i dati (ma senza bit ECC) anche se l'unità dice "errore irreversibile". Come detto nella descrizione collegata da DavidPostill, potrebbe avere esito positivo con una lettura senza errori (in realtà è più probabile "correggibile"); oppure potrebbe essere in grado di dedurre, essenzialmente calcolando la media dei bit restituiti, un'ipotesi ragionevole sui contenuti del settore. Non ha più la capacità di correggere con precisione gli errori usando l'ECC di quanto non faccia il drive; è matematicamente impossibile.

Qual è la granularità di un URE?

Gli errori di lettura non recuperabili (URE) sono errori di lettura del settore. Se il settore non può essere letto senza errori, non importa se fosse solo 1 byte o tutti i byte del settore.

La granularità è la dimensione del settore .

Anche se solo 1 byte fallisse, normalmente non si recupererebbe alcun dato da quel settore senza usare un software specializzato.

È possibile recuperare i dati di un settore guasto?

SpinRite dice:

SpinRite è persino in grado di recuperare la maggior parte dei dati in un settore che non può mai essere letto perfettamente e che qualsiasi altro software di utilità scarta completamente.

Vedi come SpinRite recupera i dati illeggibili .

Esclusione di responsabilità.

Non sono affiliato a SpinRite in alcun modo e non l'ho mai usato.

Non esiste qualcosa come "non riesco a leggere un po '", a meno che tu non abbia un grave errore hardware come la testa che non è in grado di cercare la traccia corretta, o che la servo traccia sia danneggiata e non sia possibile trovare il settore corretto . Ovviamente in entrambi i casi avresti, almeno, un intero settore illeggibile.

Altrimenti, si ottengono sempre bit, sono probabilmente bit non corretti . È qui che entra in gioco il codice di correzione degli errori; aggiunge un numero di bit ECC extra in ogni settore, in modo tale che qualsiasi combinazione corretta di bit di dati e bit ECC osservi una regola algebrica. Se tutti i bit sono stati letti correttamente, il codice verrà convalidato e i dati potranno essere passati direttamente. Se un piccolo numero di bit è stato letto in modo errato, è possibile utilizzare il codice ECC per determinare esattamente quali e correggerli, in modo che tutti i dati vengano restituiti correttamente. Se un numero maggiore di bit è stato letto in modo errato, il codice ECC può rilevare che si è verificato un errore, ma non ha più informazioni sufficienti per capire quali bit non sono corretti; questo è un errore di lettura non correggibile. Se unaun numero molto elevato di bit viene letto in modo errato, quindi il codice potrebbe essere convalidato correttamente "per errore" e l'unità restituirà dati danneggiati, ma con abbastanza bit ECC la probabilità che ciò accada può essere ridotta a piacere.

Quindi, per rispondere alla domanda, penso che stavi arrivando: se si è verificato un errore di lettura parziale ma erano disponibili informazioni sufficienti per capire dove si è verificato l'errore, allora può anche essere corretto e il computer non vedrà alcun errore . Questo in realtà accade costantemente. Un errore non corretto si verifica quando non è possibile capire quali bit di dati sono validi e quali non lo sono, e poiché il codice di correzione dell'errore viene calcolato su un settore, ciò accade alla granularità del settore.

Dopo averlo esaminato e ispirato alla risposta https://superuser.com/a/969917/160771 da https://superuser.com/users/337631/davidpostill

Vorrei rispondere presentando una risposta alternativa piuttosto estesa. Innanzitutto è vero che il disco rigido e il suo firmware sono l'origine di un evento URE, ovvero l'evento in cui i dati non possono essere letti. Inoltre è vero che i dati vengono scritti su disco in settori di 512 o 4096 byte di dati utilizzabili e circa 50 o rispettivi 100 byte di dati extra che dovrebbero consentire il controllo e la correzione degli errori.

Parlare di un URE avviene quindi naturalmente nel contesto di un settore del disco rigido. Il termine settore cattivo è sicuramente in qualche modo collegato, ma non identico alla situazione attuale quando abbiamo un settore URE.

Un settore con alcuni problemi da leggere senza errori non è necessariamente del tutto privo di significato. È possibile che in effetti tutti i 4096 dati siano stati danneggiati, ma potrebbe anche essere stato danneggiato solo 1 bit in più di quanto fosse correggibile in modo affidabile (tramite i dati ECC supplementari ridondanti aggiunti a ciascun settore).

In casese, in cui solo alcuni pochissimi byte in più rispetto a hdd sono stati in grado di correggere sono stati corrotti, ci sono cambiamenti che la frazione di 4096 byte stil ha dati significativi.

Un esempio potrebbe essere che il 4096 rappresenti i charbytes ASCII di 2 frasi. Quindi è possibile che una o più frasi del cappello siano completamente intatte. Inoltre, potrebbe essere possibile che ogni seconda o terza lettera sia stata eliminata. Se i dati di 4096 vengono persi in un evento URE dipende quindi dall'interpretazione e dipende dai dati. Si potrebbe immaginare che i dati stessi abbiano un altro strato di shell ECC, il che consentirebbe un ulteriore recupero.

Pertanto è positivo che la maggior parte dei firmware tratti i settori URE in modo diverso dai settori danneggiati:

In genere, la rimappatura automatica dei settori avviene solo quando viene scritto un settore. La logica alla base di ciò è presumibilmente che anche se un settore non può essere letto normalmente, può essere comunque leggibile con i metodi di recupero dei dati. (da https://en.wikipedia.org/wiki/Bad_sector )

O, per intenderci, potrebbe darsi che una parte del settore contenga ancora dati utilizzabili.