Comment vérifier l'état de santé d'une clé USB?
Comment savoir si une clé USB est irréparable ou réparable?
Comment vérifier l'état de santé d'une clé USB?
Comment savoir si une clé USB est irréparable ou réparable?
Réponses:
Il n’existe aucun moyen d’interroger une clé USB pour obtenir des paramètres de type SMART; À ma connaissance, aucune clé USB ne permet de le faire, même via un logiciel propriétaire accessible 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 à l’aide de badblocks
.
https://en.wikipedia.org/wiki/Badblocks
Vous voulez spécifier l'un des tests d'écriture, qui effacera toutes les données sur le stick; faites d'abord une sauvegarde.
Trouvez le périphérique en regardant dmesg
après avoir branché la clé USB; vous verrez un nom de périphérique (probablement sd_, c.-à-d. sdc, sdd, etc.) et des informations sur le fabricant. Assurez-vous que vous utilisez le bon appareil!
Si la clé est formatée avec un système de fichiers valide, vous devrez peut-être d' unmount
abord.
Exemple de syntaxe, pour une clé USB énumérée sous / dev / sdz, générant des informations de progression, avec un test d'écriture destructif des données et un journal des erreurs é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. Toute défaillance indique une défaillance du contrôleur de mémoire du périphérique ou le bloc de blocs de réserve est épuisé pour remapper les blocs en échec. Dans ce cas, aucune zone de l'appareil ne peut être sécurisée.
e2fsck -c
qui utilise badblocks
et cache efficacement ces badblocks du système de fichiers, évitant ainsi les écritures corrompues. Il convient toutefois de noter que, si le disque contient de nouveaux disques durs, il sera probablement endommagé et que de nouveaux disques arriveront plus tard, ce qui signifie que sa durée de vie est raccourcie et que vous devriez envisager de le remplacer.
Via [ubuntu] Error Check USB Flash Drive , j’ai finalement trouvé ceci, ce qui pourrait être utile:
Je suis arrivé sur les 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 ai constaté deux problèmes: (1) uniquement pour Windows et (2) il n'est pas open source. Cependant, son auteur a eu la gentillesse d'inclure un fichier texte expliquant 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 F3 se compare à H2testw puisque je n’ai jamais exécuté H2testw. J'appelle mon implémentation F3, qui est l'abréviation de Fight Flash Fraud ou Fight Fake Flash.
Addendum de @pbhj: F3 est dans le dépôt Ubuntu. Il comporte deux parties: f3write écrit des fichiers de 1 Go sur le périphérique et f3read tente de les lire par la suite. De cette façon, la capacité et la capacité d'écrire et de lire efficacement des données sont testées.
badblocks
?
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 sous Windows ou la sortie de dmesg sous Linux vous dira si le périphérique est même reconnu comme étant branché. Si ce n'est pas le cas, le contrôleur intégré ou les connexions physiques sont brisé.
Si le périphérique est reconnu comme étant branché, mais n'est pas identifié comme contrôleur de disque (et je ne sais pas comment cela pourrait se produire, mais ...), le contrôleur est abattu.
S'il est reconnu en tant que lecteur de disque, mais que vous ne pouvez pas le monter, vous pourrez peut-être le réparer via fdisk et réécrire la table de partition, puis créer un autre système de fichiers.
Si vous recherchez l'équivalent de SMART , vous ne le trouverez pas. Les contrôleurs Thumbdrive sont bon marché. Il s’agit d’un stockage de produits de base, qui n’a pas l’intelligence habituelle des lecteurs modernes.
En chemin jusqu’à aujourd’hui, ce fil de discussion a soulevé certaines questions.
- Combien de temps cela prendra-t-il (sous-entendu par une discussion sur la possibilité de le laisser tourner du jour au lendemain).
Je teste actuellement un Sandisk USB 3.0 128G avec sudo badblocks -w -s -o
, il est connecté à ma carte PCIe USB 3 / USBC dans un Athlon 64x2 plus ancien. Donc, USB3 en USB3 sur PCIe devrait être assez rapide.
Voici ma ligne de commande de la console à 33% d'achèvement:
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 non qualifiée:
For some devices this will take a couple of days to complete.
NB: Les tests ont commencé aux alentours de 20h30. Les tests avaient été terminés avant 8h45 le lendemain, soit environ 12 heures plus tard .
- Le test destructif n'est pas la seule méthode possible.
Wikipedia a offert 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 finalement que ça n'en vaut pas la peine. déclaration.
En résumé, basé sur la situation de milliards de sites de mémoire dans une puce flash, un échec est une cellule déjà écrite et effacée des dizaines de milliers de fois et qui échoue à présent. Et lorsqu'un test montre qu'une cellule a échoué, souvenez-vous que chaque fichier que vous avez ajouté et effacé exécute ces cycles.
L'idée ici est que, lorsqu'une cellule échoue, de nombreuses autres cellules atteignent également le même point d'échec. Une cellule a échoué aujourd'hui, mais vous l'utilisez normalement pendant un certain temps encore, puis 3 autres cellules échouent, puis 24 autres échouent, puis 183 et, avant même de vous en rendre compte, la matrice de mémoire est truffée de points défectueux. Un nombre limité de cellules peuvent mourir avant que votre capacité utilisable ne commence à tomber, pour finir par 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 quasiment fini en ce qui concerne le stockage digne de confiance. Votre utilisation peut encore vous donner quelques mois.
Ce sont vos données.
HTH
De nombreuses défaillances sont complètes ou permettent à un site de prendre en charge plusieurs sites. J'ai écrit un petit programme de lecture en écriture 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 décalées derrière les écritures de suffisamment de pages pour m'assurer que je ne teste pas le cache de mémoire vive sur le système. Il n'est pas encore paramétré, il suffit de configurer un périphérique 64G sur mon système avec 8G de RAM. N'hésitez pas à critiquer, paramétrer, rendre plus intelligent.
C’est un test puissant et plus rapide que tous les octets, mais il est également un excellent générateur d’échange (annule presque tout le reste). Je mets temporairement 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 le 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 ;
}
}
Les clés USB sont assez rudimentaires, il n'y a pas grand-chose qui puisse leur arriver! Généralement, si cela apparaît comme un lecteur et que vous pouvez le formater, alors cela fonctionne. Vous pouvez essayer de jeter un coup d'œil à la version Portable de CrystalDiskInfo car il s'agit d'un outil d'analyse rapide et léger. Très peu de clés USB rapportent des informations SMART et similaires.