Come verificare la salute fisica di una chiavetta USB in Linux?

Come controllare lo stato di salute di una chiavetta USB?

Come faccio a sapere se un dispositivo USB è rotto o irreparabile?

Non è possibile interrogare una memory stick USB per parametri simili a SMART; Non sono a conoscenza di memory stick che lo supportano anche tramite software proprietario disponibile al pubblico. Il meglio che puoi fare è controllare che puoi leggere + scrivere con successo sull'intero dispositivo usando badblocks.

https://en.wikipedia.org/wiki/Badblocks

Si desidera specificare uno dei test di scrittura, che cancellerà tutti i dati sullo stick; fare prima un backup.

Trova il dispositivo guardando dmesgdopo aver inserito la chiavetta USB; vedrai il nome di un dispositivo (molto probabilmente sd_, cioè sdc, sdd, ecc.) e le informazioni sul produttore. Assicurati di utilizzare il dispositivo corretto!

Se lo stick è formattato con un file system valido, potrebbe essere necessario unmountprima farlo.

Sintassi di esempio, per una chiavetta USB elencata come / dev / sdz, che fornisce informazioni sullo stato di avanzamento, con un test di scrittura distruttivo dei dati e un registro degli errori scritto su usbstick.log:

sudo badblocks -w -s -o usbstick.log /dev/sdz

Successivamente dovrai ripartizionare e riformattare il bastone, supponendo che passi; questo test cancellerà tutto sullo stick. Eventuali guasti indicano un guasto del controller di memoria del dispositivo o sono rimasti a corto di blocchi di riserva per rimappare i blocchi guasti. In tal caso, nessuna area del dispositivo può essere considerata attendibile.

Tramite [ubuntu] Error Check USB Flash Drive , ho finalmente trovato questo, che potrebbe essere utile:

• http://oss.digirati.com.br/f3/ "F3 - un'alternativa a h2testw"

Sono arrivato ai blog Fight Flash Fraud e SOSFakeFlash, che raccomandano il software H2testw (vedi qui o qui) per testare le memorie flash. Ho scaricato H2testw e ho riscontrato due problemi: (1) è solo per Windows e (2) non è open source. Tuttavia, il suo autore è stato così gentile da includere un file di testo che spiega cosa fa; questa pagina riguarda la mia implementazione GPLv3 di tale algoritmo.
La mia implementazione è semplice e affidabile e non so esattamente come F3 sia paragonabile a H2testw poiché non ho mai eseguito H2testw. Chiamo la mia implementazione F3, che è l'abbreviazione di Fight Flash Fraud o Fight Fake Flash.

Addendum di @pbhj: F3 è nei repository di Ubuntu. Ha due parti, f3write scrive i file da 1 GB sul dispositivo e f3read tenta di leggerli in seguito. In questo modo vengono testate la capacità e la capacità di scrivere e leggere in modo efficace i dati.

Dipende dalla modalità di errore, suppongo. Sono economici per un motivo.

Come dispositivo USB, guardare il bus tramite Gestione dispositivi in ​​Windows o l'output di dmesg in Linux ti dirà se il dispositivo viene persino riconosciuto come collegato. In caso contrario, il controller a bordo o le connessioni fisiche Sono rotti.

Se il dispositivo viene riconosciuto come collegato, ma non viene identificato come controller del disco (e non so come ciò possa accadere, ma ...), il controller viene girato.

Se viene riconosciuto come unità disco, ma non è possibile montarlo, è possibile ripararlo tramite fdisk e riscrivere la tabella delle partizioni, quindi creare un altro file system.

Se stai cercando l'equivalente di SMART , non lo troverai. I controller Thumbdrive sono economici. Sono lo storage delle materie prime e non intendono avere i normali failafes e l'intelligenza che hanno le unità moderne.

Lungo la strada per oggi, questo thread ha sollevato alcune domande.

- Quanto tempo ci vorrà (implicito nella discussione di lasciarlo funzionare durante la notte).

Attualmente sto testando un sandisk USB 3.0 128G usando sudo badblocks -w -s -o, è collegato alla mia scheda PCIe USB 3 / USBC in un vecchio Athlon 64x2. Quindi, USB3 in USB3 su PCIe dovrebbe essere abbastanza veloce.

Ecco la mia riga di comando della console al completamento del 33%:

Testing with pattern 0xaa: 33.35% done, 49:47 elapsed. (0/0/0 errors)

e ancora dopo:

Testing with pattern 0xaa: 54.10% done, 1:17:04 elapsed. (0/0/0 errors)

Poi è arrivato questo segmento:

Reading and comparing: 43.42% done, 2:23:44 elapsed. (0/0/0 errors)

Questo processo si ripete con oxaa, quindi 0x55, 0xff e infine 0x00.

ArchLinux ha rilasciato una dichiarazione non qualificata:

For some devices this will take a couple of days to complete.

NB: I test sono iniziati intorno alle 20:30, i test erano stati completati prima delle 8:45 del giorno successivo, completando in circa 12 ore per la mia situazione .

- I test distruttivi non sono l'unico metodo possibile.

Wikipedia ha offerto questa affermazione:

badblocks -nvs /dev/sdb This would check the drive "sdb" in non-destructive read-write mode and display progress by writing out the block numbers as they are checked.

La mia attuale pagina man sulla distribuzione conferma che -n non è distruttivo.

-n Use non-destructive read-write mode. By default only a non- destructive read-only test is done.

E infine che non ne vale la pena. dichiarazione.

Una dichiarazione riassuntiva, basata sulla situazione di miliardi di siti di memoria in un chip flash, un fallimento è una cella che è già stata scritta e cancellata decine di migliaia di volte, e ora sta fallendo. E quando un test mostra che una cella è fallita, ricorda che ogni file che hai aggiunto e cancellato esegue quei cicli.

L'idea qui è che quando una cella si guasta, molte più celle raggiungono lo stesso punto di errore. Una cella ha fallito oggi, ma la usi normalmente per un po 'di più, quindi altre 3 celle falliscono, quindi altre 24 falliscono, quindi 183, e prima di conoscerla, l'array di memoria è pieno di punti negativi. Ci sono solo così tante cellule che possono morire prima che la tua capacità utilizzabile inizi a diminuire, alla fine diminuendo rapidamente. Come saprai che più cellule non funzionano? Quindi, i post qui proteggono i tuoi dati dicendo che una volta che hai una cella difettosa, hai praticamente finito per quanto riguarda l'archiviazione affidabile. Il tuo utilizzo potrebbe ancora darti qualche mese.

Sono i tuoi dati.

HTH

Molti guasti sono completi o consentono a una posizione di supportare più posizioni. Ho scritto un piccolo programma di lettura in scrittura casuale che utilizza un numero primo per un generatore di numeri pseudo-casuali, sia per i modelli che per gli indirizzi. Le letture sono scaglionate dietro le scritture da pagine sufficienti per assicurarsi che non sto testando la RAM RAM sul sistema. Non è ancora parametrizzato, è solo impostato per un dispositivo 64G sul mio sistema con ram 8G. Sentiti libero di criticare, parametrizzare, renderlo più intelligente.

Questo è un controllo potente e più veloce di ogni byte dal basso verso l'alto, ma è anche un ottimo generatore di swap (fa rotolare quasi tutto il resto). Ho impostato temporaneamente lo swapiness su 1 ed è diventato più lento ma più tollerabile con altre app. Qualche consiglio su come sintonizzarsi contro lo swapout sarebbe anche apprezzato:

$ sudo ksh -c 'echo 1> / proc / sys / vm / swappiness'

$ cat mysrc/test64g.c

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>

int main( int argc, char **argv ){

        long long int mask = 0xFFFFFFFF8L ;    // 64Gb word
        long long int stag = 8413257 ;  // 8G / 1021
        long long int inc = 1021L ;     // prime < 1024

        long long int w_addr = 0L ;
        long long int r_addr = 0L ;
        long long int w_ct = 0L ;
        long long int r_ct = 0L ;
        long long int w_patt = 0xFEDCBA9876543210L ;
        long long int r_patt = 0xFEDCBA9876543210L ;
        long long int r_buf ;
        int fd, ret ;

        if ( argc < 2
          || argv[1] == NULL
          || 0 > ( fd = open( argv[1], O_RDWR ))){
                printf( "Fatal: Cannot open file $1 for RW.\n" );
                exit( 1 );
        }

        while ( 1 ){
                if ( (off_t)-1 == lseek( fd, w_addr & mask, SEEK_SET )){
                        printf( "Seek to %llX\n", w_addr & mask );
                        perror( "Fatal: Seek failed" );
                        exit( 2 );
                }

                if ( 8 != ( ret = write( fd, (void*)&w_patt, 8 ))){
                        printf( "Seek to %llX\n", w_addr & mask );
                        perror( "Fatal: Write failed" );
                        exit( 3 );
                }

                w_ct++ ;
                w_addr += inc ;
                w_patt += inc ;

                if ( ( w_ct - r_ct ) < stag ){
                        continue ;
                }

                if ( (off_t)-1 == lseek( fd, r_addr & mask, SEEK_SET )){
                        printf( "Seek to %llX\n", r_addr & mask );
                        perror( "Fatal: Seek failed" );
                        exit( 4 );
                }

                if ( 8 != ( ret = read( fd, (void*)&r_buf, 8 ))){
                        printf( "Seek to %llX\n", w_addr & mask );
                        perror( "Fatal: Read failed" );
                        exit( 5 );
                }

                if ( ( ++r_ct & 0XFFFFF ) == 0 ){
                        printf( "Completed %lld writes, %lld reads.\n", w_ct, r_ct );
                }

                if ( r_buf != r_patt ){
                        printf( "Data miscompare on read # %lld at address %llX:\nWas: %llX\nS/B: %llX\n\n", r_ct, r_addr & mask, r_buf, r_patt );
                }

                r_addr += inc ;
                r_patt += inc ;
        }
}

Le unità USB sono piuttosto rudimentali, non c'è molto che possa andare storto! In genere, se viene visualizzato come unità e puoi formattarlo, allora funziona. Potresti provare a dare un'occhiata alla versione Portable di CrystalDiskInfo in quanto è uno strumento di analisi rapido e leggero. Pochissime chiavette USB riportano informazioni SMART e simili.