J'ai écrit un outil simple pour cela, il s'appelle CapacityTester (capture d'écran) et il dispose d'une interface graphique et d'une interface de commande.

Il y a un binaire précompilé pour Debian 7 disponible au téléchargement qui a toutes les chances de fonctionner d'emblée sur un système Ubuntu moderne.

Je l'ai écrit pour mon usage personnel car je n'ai pas trouvé d'outil graphique à cet effet. Il vous suffit de monter votre clé USB vide, de la sélectionner et de lancer le test. C'est un outil très bête car tout ce qu'il fait est de remplir la clé avec des fichiers et de vérifier que les données sur la clé sont correctes. Il interrompt le test à la première erreur (écriture ou lecture/vérification). Il indique le décalage du morceau qui n'a pas pu être écrit ou vérifié avec succès, mais il s'agit d'un décalage logique. Cette information peut donc être inutile, car elle dépend du système de fichiers dans lequel les fichiers sont situés sur le disque. Toutefois, lorsque le disque a été rempli de données et que tout a pu être lu et vérifié, on peut supposer que la capacité déclarée du disque est correcte. Par ailleurs, les fichiers de test sont automatiquement supprimés (cela peut ne pas fonctionner si le disque est défectueux).

Là encore, c'est très simple, car cela ne fonctionne qu'avec des fichiers situés au-dessus d'un système de fichiers existant. Il y a donc quelques Ko (+ 1M buffer) qui ne peuvent pas être testés. Et il est très lent parce qu'il remplit vraiment tout le système de fichiers. F3 est certainement beaucoup plus sophistiqué et aussi plus rapide, mais il n'a pas d'interface graphique. La seule raison pour laquelle CapacityTester existe est qu'il possède une interface graphique afin de pouvoir être utilisé par les utilisateurs qui ne sont pas familiers avec la ligne de commande ou qui préfèrent simplement une interface graphique.

Les commentaires sont appréciés.

Le comportement de l'OP et la "fausse conduite" sont abordés

Je modifie la réponse pour aborder correctement certains points, car le PO a été très véhément (et, à mon avis, s'est opposé à la plupart des commentaires et des réponses, à l'exception de la sienne, que je trouve suspecte). En particulier, il y a beaucoup d'affirmations sur l'existence de "faux lecteurs", mais il n'y a pas de définition claire de ce que cela signifie réellement. L'OP a déclaré :

Je pourrais simplement copier des choses dessus, les recopier et vérifier si les fichiers sont corrects. Je pourrais aussi l'automatiser avec des hachages et d'autres choses. Mais j'espère qu'il existe une solution plus précise.

L'OP lui-même a admis qu'il pouvait "simplement copier des choses" et vérifier l'intégrité des données, mais il s'est opposé à tous les autres commentaires et réponses qui proposaient autre chose et l'OP n'a cessé de présenter F3 comme la "vraie affaire". La question elle-même a d'abord porté sur la taille du disque, puis, pour une raison quelconque, l'utilisateur a mentionné les hachages pour "vérifier si les fichiers sont corrects", comme s'il existait des disques mystérieux qui revendiquent une taille et vous permettent d'écrire cette taille, mais dont les données sont ensuite corrompues. Par conséquent, je trouve cela très suspect et je considérerais la promotion de F3 par l'OP comme une question-réponse de spam.

Quand un lecteur est en fait un faux lecteur

Dans la question, la définition apparente de l'OP est la suivante

" des disques qui prétendent avoir beaucoup d'espace (souvent poussé trop loin, comme 128 Go), alors qu'ils n'offrent physiquement que 0,5 à 4 Go."

En d'autres termes, selon l'OP, le réclamations des contrôleurs X de données, mais l'USB ne peut que contenir quelque chose comme 80-90 % de moins que ce qui est revendiqué.

L'utilisateur sudodus proposée dans le commentaires (soulignement ajouté) : "J'ai constaté que plusieurs clés USB sont légèrement plus petites que la taille nominale. Je les appelle sous-dimensionné . Je pense que les faux lecteurs sont "largement sous-dimensionné". (généralement la moitié du calibre nominal ou moins )". Cette définition est excellente, mais si nous la prenons, un faux disque est défini à 50 %. Un disque qui revendique 64 Go mais ne peut contenir que 32 Go perd techniquement la moitié de sa valeur pour le propriétaire et celui-ci ne peut y mettre que la moitié de ce qu'il avait prévu.

Je propose une définition plus simple : un dispositif de stockage contrefait est celui qui prétend avoir Claimed Size mais est inférieure à la tolérance de 15% (et la tolérance est Claimed Size ± 15 % ).

Les ± 15 % est très raisonnable. Il faut également tenir compte du fait que les utilisateurs confondent généralement les organisations Unix, IEEE et IEC qui utilisent un préfixe binaire au lieu d'une puissance de 10 pour la taille de stockage des données. La différence atteint 20 % au niveau du préfixe yotta, mais les clés USB n'en sont pas encore là, de sorte que pour les 20 prochaines années peut-être, 15 % sont raisonnables. (Voir la question askubuntu Signification du "i" dans "MiB"". y Préfixe binaire )

Test du lecteur

En effet, l'utilisateur n'a besoin d'aucun outil particulier, à part ceux qui sont déjà fournis avec Ubuntu et la plupart des systèmes Unix compatibles POSIX. Soulignons et reformulons la définition :

Si nous ne pouvons pas écrire la quantité de données sur le disque et que ce que nous écrivons se situe dans la tolérance de 15 %, le disque est en bon état.

a façon la plus simple de le faire est d'utiliser dd Pour cela, il suffit d'écraser le périphérique avec des zéros (et bien sûr, n'oubliez pas de sauvegarder vos fichiers avant d'effectuer cette opération).

sudo dd if=/dev/zero of=/dev/sdb1 iflag=nocache oflag=direct bs=1                        

Notez que les bs=1 pour une taille de bloc de 1 octet. Les dd Le commandement donne généralement un rapport sur le montant des écritures.

$ dd if=/dev/zero of=/dev/null bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00261981 s, 391 kB/s

Nous lui avons demandé d'écrire 1024 octets, il a écrit 1024 octets.

Une liste plus précise des étapes conformes à la définition serait la suivante :

• Déterminez la quantité de données que le lecteur réclame (en supposant que vous soupçonnez que le lecteur a été endommagé). df d'être "dans l'erreur"). Dans cet exemple, supposons que /dev/sdb1 est mon fichier de périphérique pour la clé USB :

  $ df -P /dev/sdb1 | awk 'NR==2{print $2}'
  115247656

  Il convient de noter que -P est destiné à la portabilité POSIX, ce qui signifie que la taille des blocs de données sera de 1024 octets, ce qui signifie qu'il y a 115247656*1024 octets sur ce disque.

• Déterminez la tolérance de 15 % en dessous de ce que le lecteur déclare (115247656), en utilisant éventuellement un utilitaire qui prend en charge le calcul en virgule flottante, tel que awk :

   $ awk 'BEGIN{printf "%d\n",115247656*(1-0.15)}'
   97960507

• Créez des données aléatoires sur le disque dur de la même taille que le disque de l'étape précédente pour l'utiliser comme référence : dd if=/dev/urandom of=./mytestfile.random bs=1024 count=97960507

• Maintenant, écrivez les données dd if=./mytestfile.random of=/dev/sda1 . Si le lecteur peut contenir cette quantité, il est "réel". Vous pouvez également prendre md5sum o sha1sum de la ./mytestfile.random et comparer avec /dev/sda1 maintenant. Une meilleure amélioration consisterait à écrire le mytestfile.random au point de montage du fichier, ce qui permet de conserver le système de fichiers sur le disque et de ne pas modifier le partitionnement du disque, en d'autres termes

  dd if=./mytestfile.random of=/mountpoint/for/usb/drive/testfile.random

• Pour l'intégrité, vous pouvez alors effectuer n'importe quelle vérification par hashsum, comme par exemple md5sum , sha1sum , sha256sum ou autres. A titre d'exemple, on peut citer

  md5sum ./mytestfile.random  /mountpoint/for/usb/drive/testfile.random

  L'essentiel est que si la quantité de données écrites se situe dans les limites de la tolérance et produit une somme de contrôle correcte avant et après l'écriture, le lecteur est probablement en bon état.

Tout cela peut être mis dans un joli script pour plus de commodité, si on le souhaite.

Conclusion

Cette question ressemble plus à une "promotion" de ce que l'OP aime, et il semble que l'OP soit beaucoup moins intéressé par le fait de tester les lecteurs. En outre, le problème lui-même est plus humain que le problème du "disque". Dans les commentaires, l'OP lui-même a déclaré qu'il ne comprenait pas vraiment le comportement de l'USB, mais qu'il était prêt à blâmer "le contrôleur". Je laisserai cette question en 3 points :

• Déterminez clairement quel est le problème que vous essayez de résoudre et quelle est la définition d'un "faux disque".
• Essayer de comprendre les utilités de base d'Unix
• W