web-dev-qa-db-fra.com

Comment puis-je tester la capacité totale d'une carte SD sous Linux?

J'ai acheté une carte SD de 64 Go sur eBay. Cela fonctionne bien lorsque je grave une image Arch Linux ARM et l’utilise pour démarrer mon Raspberry Pi.

Cependant, lorsque j'essaie de créer une seule partition ext4 sur celle-ci pour utiliser toute la capacité de la carte, des erreurs se produisent. mkfs.ext4 finit toujours avec bonheur; Cependant, la partition ne peut pas être mounted, une erreur est toujours générée et dmesg indique que les messages du noyau incluent Cannot find journal. Cela s'est avéré être le cas sur au moins deux plates-formes: Arch Linux ARM et Ubuntu 13.04.

Par ailleurs, je peux créer et monter une partition FAT32 sans erreur (aucune vérification de la capacité totale n'a été effectuée).

J'ai entendu dire que certains méchants peuvent modifier l'interface de la carte SD pour signaler une capacité incorrecte au système d'exploitation (c'est-à-dire que la carte ne représente en réalité que 2 Go mais se présente comme un disque de 64 Go) afin de vendre la carte à un meilleur prix.

Je sais qu'il existe des outils tels que badblocks pour vérifier si la carte SD contient des blocs défectueux. badblocks peut-il détecter des problèmes comme celui-ci? Si non, quelles autres solutions existent pour moi pour tester la carte?

J'aimerais idéalement savoir si j'ai été trompé ou non; si le résultat indique que je viens de recevoir un article défectueux, je ne peux que retourner au vendeur, signaler plutôt à eBay que quelqu'un a tenté de me tromper.

UPDATE

opérations et messages:

~$ Sudo mkfs.ext4 /dev/sde1
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
4096000 inodes, 16383996 blocks
819199 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
500 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
4096000, 7962624, 11239424

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done   

~$ dmesg | tail
...
[4199.749118]...
~$ Sudo mount /dev/sde1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sde1,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail  or so

~$ dmesg | tail
...
[ 4199.749118]...
[ 4460.857603] JBD2: no valid journal superblock found
[ 4460.857618] EXT4-fs (sde1): error loading journal

UPDATE

J'ai exécuté badblocks /dev/sde mais il ne rapporte aucune erreur. Cela signifie que les causes restantes sont:

  • La voiture SD est bonne mais pour une raison quelconque, mke2fs ou mount ou le noyau ont un bogue qui cause le problème.

  • J'ai été trompé d'une manière qui badblocks qui ne peut pas détecter la défaite. Ceci est plausible car je pense que badblocks est en train de faire un test d'écriture-lecture sur place. Cependant, le tricheur peut rendre l'accès aux zones sortantes lié à un bloc entrant. Dans ce cas, une vérification sur place d'écriture-lecture n'est pas en mesure de détecter le problème.

S'il n'y a aucune application capable de faire le test approprié, je pense que je peux essayer d'écrire un simple programme en C pour le tester.

sd-cardbad-blocks
16
Earth Engine

Si quelqu'un le voit plus tard: Quelqu'un a écrit un outil open source appelé "F3" pour tester la capacité des cartes SD et autres supports de ce type. On peut le trouver sur le projet et en Github .

25
Radtoo

La triche a maintenant été confirmée par les étapes suivantes:

  • Générez un fichier de données aléatoire. (4194304 = 4 × 1024 × 1024 = 4 Mo, taille totale = 40 × 4 Mo = 160 Mo)

    Commander:

    dd if=/dev/urandom of=test.orig bs=4194304 count=40
40+0 records in
40+0 records out
167772160 bytes (168 MB) copied, 11.0518 s, 15.2 MB/s

  • Copiez les données sur la carte SD. (2038340 × 4096 = 8153600 Ko = 7962,5 Mo)

    Commander:

    Sudo dd if=test.orig of=/dev/sde seek=2038399 bs=4096
40960+0 records in
40960+0 records out
167772160 bytes (168 MB) copied, 41.6087 s, 4.0 MB/s

  • Lire les données de la carte SD.

    Commander:

    Sudo dd if=/dev/sde of=test.result skip=2038399 bs=4096 count=40960
40960+0 records in
40960+0 records out
167772160 bytes (168 MB) copied, 14.5498 s, 11.5 MB/s

  • Afficher le résultat

    Commander:

    hexdump test.result | less
...
0000ff0 b006 fe69 0823 a635 084a f30a c2db 3f19
0001000 0000 0000 0000 0000 0000 0000 0000 0000
*
1a81000 a8a5 9f9d 6722 7f45 fbde 514c fecd 5145

...

Qu'est-il arrivé? Nous avons observé un écart de zéros. C'est un indicateur que les données aléatoires n'ont pas été réellement écrites sur la carte. Mais pourquoi les données reviennent-elles après 1a81000? De toute évidence, la carte a un cache interne.

Nous pouvons également essayer d'étudier le comportement du cache.

hexdump test.orig | grep ' 0000 0000 '

ne donne aucun résultat, ce qui signifie que les ordures générées ne présentent pas un tel motif. cependant,

hexdump test.result | grep ' 0000 0000 '
0001000 0000 0000 0000 0000 0000 0000 0000 0000
213b000 0000 0000 0000 0000 0000 0000 0000 0000
407b000 0000 0000 0000 0000 0000 0000 0000 0000
601b000 0000 0000 0000 0000 0000 0000 0000 0000

avoir 4 allumettes.

C’est la raison pour laquelle il passe badblocks check. Des tests supplémentaires peuvent montrer que la capacité réelle est de 7962,5 Mo, soit un peu moins de 8 Go.

Je conclus qu’il est très peu probable qu’il s’agisse d’une défaillance matérielle aléatoire, mais plutôt d’une sorte de triche (fraude). J'aimerais savoir quelles mesures je peux prendre pour aider d'autres victimes.

Mise à jour 11/05/2019

  • Des gens m'ont demandé comment je pouvais comprendre que le paramètre seek correct est 2038399. J'ai fait beaucoup plus d'expérience que ce que j'ai montré ci-dessus. Fondamentalement, vous devez deviner en premier lieu. Vous devez deviner la taille appropriée des données et deviner où la corruption de données s'est produite. Mais vous pouvez toujours utiliser méthode de bissection pour vous aider.

  • Dans le commentaire ci-dessous, je pensais que la deuxième étape ci-dessus (copier les données sur la carte SD) ne copie qu'un secteur. Mais je n'ai pas fait cette erreur dans mon expérience. Au lieu de cela, seek devait montrer que dans l'étape "show result", l'offset 1000 se produisait simplement dans le deuxième secteur des données. Si seek correspond à 2038399 secteurs, la corruption se situe au 2038400e secteur.

6
Earth Engine

Tout d’abord, lisez la réponse F de @Radtoo. C'est la bonne façon.

J'ai raté ça et essayé ma propre voie:

  1. créer un fichier test de 1 Go: dd if=/dev/urandom bs=1024k count=1024 of=testfile1gb

  2. écrire des copies de ce fichier sur sdcard (64 est la taille de sdcard en gb): for i in $(seq 1 64); do dd if=testfile1gb bs=1024k of=/media/sdb1/test.$i; done

  3. vérifie md5 des fichiers (tous sauf le dernier, incomplets, doivent correspondre): md5sum testfile1gb /media/sdb1/test.*

3
domen

J'ai écrit un petit script qui fait ce qui suit.

- crée un répertoire temporaire sur la carte USB ou SC cible

Avec ce script, j'ai conclu que j'avais été arnaqué par un vendeur sur eBay qui a adopté une microSD de 8 Go pour une mémoire de 64 Go.

#!/bin/bash
#Save file as 'filltext' and remember to set the executable flag to run it
if [ -d "$1" ]; then
 if [ -d "$1/tmp" ]; then
  echo "."
 else
  mkdir $1/tmp
 fi

#Make a tmp file and fill it with 3MB of junk
 TMPTSTR=$(mktemp)      
 base64 </dev/urandom  | head -c 5000000 > $TMPTSTR

 TESTVAL=$(md5sum $TMPTSTR | awk '{ print $1 }')

 while $CHECKEDOK; do

  FL=$( tr -dc A-Za-z0-9 </dev/urandom  | head -c 5).TEST

  cp $TMPTSTR $1/tmp/$FL
  TESTTMP=$(md5sum $1/tmp/$FL | awk '{ print $1 }')
  if [ "$TESTVAL" != "$TESTTMP" ]; then   
   echo "Checksum ERROR"
   echo "Original: $TESTVAL Temp File:$TESTTMP"
   CHECKEDOK=false
   df $1 -Ph
   echo 
   echo 
   echo "Removing test files"
   rm $1/tmp -r
   rm $TMPTSTR
   df $1 -Ph
  else
   #echo -n "$FL..."
   clear
   df $1 -Ph
  fi
 done

else
 echo "Error: Directory $1 does not exists."
 echo "Usage: filltest [PATH]"
 echo
 echo "Try the PATH of a mounted USB dongle or SD card to confirm it's capacity"

fi
2
Robert Charest

Le moyen le plus simple de tester la capacité totale d'une carte SD consiste à la remplir de fichiers, puis à vérifier que les fichiers sont corrects: diff -qr /directory/on/computer /directory/on/SD

Vous pouvez également utiliser des programmes pour écrire des modèles, ou des chaînes de hachages, dans un fichier, puis vérifier qu'ils sont corrects.

Comme @ Earthy Engine a souligné, il est important de remplir la carte SD, puis de lire les données, car les approches traditionnelles qui écrivent simplement un petit bloc de données, puis le lisent, sont trompées par de fausses cartes SSD. .

2
Zaz

On peut écrire une séquence de nombres (chaque rangée est de 16 octets) puis vérifier le contenu:

dd if=<(seq -w 0 123456789012345) of=/dev/yourSdHere

Vérifiez ensuite skip == output (en utilisant un petit échantillon de valeurs skip correspondant à un plus petit nombre d'enregistrements écrits), par exemple. skip = 9876:

dd if=/dev/yourSdHere bs=16 count=1 skip=9876
000000000009876
1+0 records in
1+0 records out
16 bytes copied, ...

Ou, faites un échantillon de 20 emplacements avec une seule doublure:

seq -w 000000000000000 NumberOfWrittenRecords | shuf | head -20 | while read i; do [[ $(dd if=/dev/yourSdHere bs=16 count=1 skip=$i) == $i ]] && echo ok || echo bad; done
  • Assurez-vous que vous écrivez sur la carte SD
  • Ecrivez dans un fichier of=tempFileOnSD, si vous souhaitez éviter de détruire les données stockées sur votre carte (pertinent uniquement si ce n'est pas un faux)
  • Dans le cas d'une carte de 8 Go portant la mention 64 Go, la chance de réussir les 20 tests est de (8 Go/64 Go) ** 20 <1e-18
1
karpada