Question Comment vérifier la santé physique d'une clé USB sous Linux?


Comment vérifier l'état de santé d'une clé USB?

Comment savoir si une clé USB est irrémédiablement réparable ou réparable?


70
2018-01-08 23:26


origine


Jette-le. Votre temps investi est plus cher que l'achat d'un nouveau. - mailq
Je suis d'accord avec @mailq. Vous pouvez acheter une clé USB 4 Go décente pour 2,00 $ ces jours-ci. - iglvzx
@iglvzx Eh bien la question ne dit pas, si c'est un bon marché, ou un cryptage rapide de + 32Gb ... - varesa


Réponses:


Il n'y a aucun moyen d'interroger une clé USB pour les paramètres de type SMART; Je ne suis pas au courant de toutes les clés USB qui prennent en charge de le faire, même via des logiciels propriétaires disponibles au public. Le mieux que vous puissiez faire est de vérifier que vous pouvez lire et écrire avec succès sur l’ensemble du périphérique en utilisant badblocks.

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

Vous voulez spécifier l'un des tests d'écriture, qui effacera toutes les données de la clé; Faites d'abord une sauvegarde.

Trouvez l'appareil en regardant dmesg après avoir branché la clé USB; vous verrez un nom d'appareil (probablement sd_, c.-à-d. sdc, sdd, etc.) et des informations sur le fabricant. Assurez-vous d'utiliser le bon appareil!

Si la clé est formatée avec un système de fichiers valide, vous devrez peut-être unmount c'est d'abord

Exemple de syntaxe, pour une clé USB énumérée sous la forme / dev / sdz, fournissant des informations de progression, avec un destructeur de données écrire le journal de test et d'erreur écrit dans usbstick.log:

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

Vous aurez besoin de repartitionner et de reformater le stick par la suite, en supposant qu'il passe; Ce test va tout effacer sur le bâton. Tout échec indique une défaillance du contrôleur de mémoire du périphérique ou il est à court de blocs de rechange pour remapper les blocs défaillants. Dans ce cas, aucune zone de l'appareil ne peut être approuvée.


61
2018-01-09 03:58



badblocks est probablement la meilleure option. les commentaires qui disent "ne vaut pas la peine" manquent complètement plusieurs cas où cela peut être très nécessaire (par exemple, une entreprise peut avoir acheté des flashdrives de marchandises et aimerait voir à quel point ils se sont fait arnaquer ...) - Richlv
comme indiqué dans l'article de wikipedia lié, il y a aussi e2fsck -c qui utilise badblocks et cache efficacement ces badblocks du système de fichiers, évitant ainsi les écritures corrompues. Il convient de noter cependant que si le disque a de nouveaux badblocks, il est probablement endommagé et de nouveaux peuvent arriver plus tard, ce qui signifie que sa durée de vie se réduit et que vous devriez envisager de le remplacer. - igorsantos07
Je suggère d'ajouter le drapeau -v ainsi que l'erreur dans les fenêtres du terminal. (par exemple, si vous le laissez fonctionner pendant la nuit. Le fichier journal n’est pas très utile pour un aperçu rapide de la situation. - Tilo
@BeeDee, devrions-nous utiliser un périphérique entier ou simplement une partition ou peu importe? Je veux dire / dev / sdz ou / dev / sdz1? - Mr. P
@Pisek vous devez utiliser un périphérique entier, car il est le périphérique défaillant, pas seulement une partition. - Hi-Angel


Via [Ubuntu] Vérification d'erreur Clé USB, J'ai finalement trouvé ce qui pourrait être utile:

Je suis arrivé aux blogs Fight Flash Fraud et SOSFakeFlash, qui recommandent le logiciel H2testw (voir ici ou ici) pour tester les mémoires flash. J'ai téléchargé H2testw et trouvé deux problèmes avec celui-ci: (1) c'est uniquement pour Windows, et (2) ce n'est pas open source. Cependant, son auteur a eu la gentillesse d'inclure un fichier texte qui explique ce qu'il fait; Cette page concerne mon implémentation GPLv3 de cet algorithme.
  Mon implémentation est simple et fiable, et je ne sais pas exactement comment comparer F3 à H2testw, car je n'ai jamais lancé H2testw. J'appelle mon implémentation F3, ce qui est l'abréviation de Fight Flash Fraud, ou Fight Fake Flash.

Addendum par @pbhj: F3 est dans les pensions Ubuntu. Il a deux parties, f3write écrit des fichiers de 1 Go sur le périphérique et f3read tente de les lire ensuite. De cette façon, la capacité et la capacité d’écrire et de lire efficacement les données sont testées.


17
2018-04-29 06:20



Y a-t-il un avantage à F3 sur badblocks? - Zaz
@Zaz Aussi bien que je le comprends, badblocks n'est pas conçu pour détecter les fausses clés USB et ne peut rapporter aucune erreur pour eux. - bmaupin


Cela dépend du mode de défaillance, je suppose. Ils sont bon marché pour une raison.

En tant que périphérique USB, regarder le bus via le gestionnaire de périphériques de Windows ou la sortie de dmesg sous Linux vous indiquera si le périphérique est même reconnu comme branché. Si ce n’est pas le cas, le contrôleur embarqué ou les connexions physiques sont brisé.

Si le périphérique est reconnu comme étant branché, mais n’est pas identifié en tant que contrôleur de disque (et je ne sais pas comment cela pourrait se produire, mais…), le contrôleur est déclenché.

S'il est reconnu en tant que lecteur de disque, mais que vous ne pouvez pas le monter, vous pouvez le réparer via fdisk et réécrire la table de partition, puis créer un autre système de fichiers.

Si vous cherchez l'équivalent de INTELLIGENT., alors vous ne le trouverez pas. Les contrôleurs Thumbdrive sont bon marché. Ils sont un stockage de base, et ne sont pas destinés à avoir les défaillances normales et l'intelligence que possèdent les lecteurs modernes.


14
2018-01-08 23:33





De nombreuses pannes sont soit complètes, soit autorisent un emplacement à prendre en charge plusieurs emplacements. J'ai écrit un petit programme de lecture aléatoire qui utilise un nombre premier pour un générateur de nombres pseudo-aléatoires, à la fois pour les modèles et les adresses. Les lectures sont échelonnées derrière les écritures par suffisamment de pages pour garantir que je ne teste pas le cache RAM sur le système. Il n'est pas encore paramétré, il suffit de configurer un appareil 64G sur mon système avec 8G ram. N'hésitez pas à critiquer, paramétrer, rendre plus intelligent.

C'est un contrôle puissant et plus rapide que de faire chaque octet de bas en haut, mais c'est aussi un excellent générateur de swap (il fait presque tout le reste). Je mets temporairement le swapiness à 1 et il est devenu plus lent mais plus tolérable pour les autres applications. Tous les conseils sur la façon de régler contre swapout seraient également appréciés:

$ 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 ;
        }
}

1
2017-08-14 19:56



Utiliser une puissance de 2 comme 1024 permettrait une meilleure vérification ou des bits d’adresse hauts morts, en ne vérifiant que 8 octets par bond. - David Pickett
oui, cela manquera le cas des hauts bits morts. faire aussi des lectures et écrit dans le même passage peut manquer cela, - user313114


Les clés USB sont assez rudimentaires, il n’ya pas grand chose qui puisse mal tourner! En général, s’il s’agit d’un lecteur et que vous pouvez le formater, cela fonctionne. Vous pouvez essayer de regarder le Version portable de CrystalDiskInfo comme c'est un outil d'analyse rapide et léger. Très peu de clés USB rapportent S.M.A.R.T. info et autres si.


0
2018-01-08 23:30



Pour référence, voici le manuel Crystal Disk Info en anglais: crystalmark.info/software/CrystalDiskInfo/manual-fr - Matt Simmons


En chemin, ce fil a soulevé quelques questions.

-Combien de temps cela prendra (implicite dans la discussion de laisser courir pendant la nuit).

Je teste actuellement un Sandisk USB 3.0 128G en utilisant sudo badblocks -w -s -o, il est connecté à ma carte PCIe USB 3 / USBC dans un Athlon 64x2 plus ancien. Ainsi, USB3 dans USB3 sur PCIe devrait être assez rapide.

Voici la ligne de commande de la console à 33%:

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

et encore plus tard:

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

Ensuite est venu ce segment:

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

Ce processus se répète avec oxaa, puis 0x55, 0xff et enfin 0x00.

ArchLinux a donné une déclaration sans réserve:

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

N.B .: Les tests ont débuté vers 20h30, les tests ont été terminés avant 8h45 le lendemain, complétant environ 12 heures pour ma situation.

-Les tests destructifs ne sont pas la seule méthode possible.

Wikipedia a proposé cette déclaration:

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.

Ma page de manuel de distribution actuelle confirme que -n est non destructif.

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

Et enfin que ça ne vaut pas la peine. déclaration.

Une déclaration récapitulative, basée sur la situation de milliards de sites de mémoire dans une puce flash, une défaillance est une cellule qui a déjà été écrite et effacée des dizaines de milliers de fois et qui est en train d’échouer. Et lorsqu'un test montre qu'une cellule a échoué, rappelez-vous que chaque fichier que vous avez ajouté et effacé exécute ces cycles.

L'idée ici est que lorsque 1 cellule tombe en panne, beaucoup plus de cellules atteignent également le même point de défaillance. Une cellule a échoué aujourd'hui, mais vous l'utilisez normalement pendant un certain temps, puis 3 autres cellules échouent, puis 24 autres échouent, puis 183, et avant que vous ne le sachiez, la matrice de mémoire est remplie de mauvaises zones. Il y a tellement de cellules qui peuvent mourir avant que votre capacité utilisable ne commence à tomber, pour finalement tomber rapidement. Comment saurez-vous que plus de cellules échouent? Ainsi, les publications ici protègent vos données en disant qu'une fois que vous avez une mauvaise cellule, vous êtes pratiquement terminé en ce qui concerne le stockage fiable. Votre utilisation peut encore vous donner quelques mois.

C'est vos données.

HTH


0
2018-06-07 01:01