J'ai acheté une carte SD de 64 Go sur eBay. Cela fonctionne bien lorsque je lui grave une image Arch Linux ARM et que je l'utilise pour démarrer mon Raspberry Pi.
Cependant, lorsque j'essaie de créer une seule partition ext4 dessus 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 mount
éditée, générant toujours une erreur et dmesg
affichant les messages du noyau inclus Cannot find journal
. Cela s'est avéré être le cas sur au moins deux plates-formes: Arch Linux ARM et Ubuntu 13.04.
D'un autre côté, je peux créer et monter une partition FAT32 sans erreur (une vérification de la pleine capacité n'a pas été effectuée).
J'ai entendu dire que certains méchants peuvent changer l'interface de la carte SD pour signaler une mauvaise capacité au système d'exploitation (c'est-à-dire que la carte n'est vraiment que de 2 Go mais elle se présente comme 64 Go) afin de vendre la carte à un meilleur prix.
Je sais que des outils comme celui-ci badblocks
existent pour moi de vérifier la carte SD pour les blocs défectueux. Peut badblocks
détecter des problèmes comme celui-ci? Sinon, quelles sont les autres solutions pour tester la carte?
J'aimerais idéalement savoir si j'ai été trompé ou non; si le résultat montre que je viens de recevoir un mauvais article, je peux retourner au vendeur uniquement, plutôt signaler à eBay que quelqu'un a essayé de me tromper.
MISE À JOUR
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
MISE À JOUR
J'ai couru badblocks /dev/sde
mais il ne signale aucune erreur. Cela signifie que les causes restantes sont:
La voiture SD est bonne mais pour une raison
mke2fs
oumount
une autre, le noyau a un bogue qui cause le problème.J'ai été trompé d'une manière qui
badblocks
ne puisse pas détecter la défaite. C'est plausible parce que je pense quebadblocks
c'est juste faire un test d'écriture-lecture sur place. Cependant, le tricheur peut relier l'accès aux zones sortantes à un bloc entrant. Dans ce cas, une vérification en lecture-écriture sur place n'est pas en mesure de détecter le problème.
S'il n'y a pas d'application qui puisse faire le bon test, je pense que je peux essayer d'écrire un simple programme C pour le tester.
la source
dmesg
montre les messages du noyau et je suis sûr qu'il apparaît en même temps que les erreurs car je l'ai fait avant et après et les ai comparés. Je n'ai pas vérifiésyslog
parce que je croisdmesg
affichera les messages.Réponses:
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. Il peut être trouvé sur l'hompage du projet et dans Github .
la source
La tricherie a maintenant été confirmée par les étapes suivantes:
Générez un fichier de données aléatoire. (4194304 = 4 × 1024 × 1024 = 4 Mio, taille totale = 40 × 4 Mio = 160 Mio)
Commander:
Copiez les données sur la carte SD. (2038340 × 4096 = 8153600 Kio = 7962,5 Mio)
Commander:
Lisez les données de la carte SD.
Commander:
Afficher le résultat
Commander:
Qu'est-il arrivé? Nous avons observé un écart de zéros. Ceci indique 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
? Évidemment, la carte a un cache interne.Nous pouvons également essayer d'enquêter sur le comportement du cache.
ne fournit aucun résultat, ce qui signifie que les déchets générés n'ont pas un tel modèle. cependant,
avoir 4 matchs.
C'est pourquoi il passe le
badblocks
contrôle. 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 simplement d'une défaillance matérielle aléatoire, mais plus susceptible d'être une sorte de tricherie (c'est-à-dire de fraude). Je voudrais savoir quelles mesures je peux prendre pour aider d'autres victimes.
Mise à jour 11/05/2019
Les gens m'ont demandé comment j'ai trouvé le bon
seek
paramètre2038399
. J'ai fait beaucoup plus d'expérience que ce que j'ai montré ci-dessus. Fondamentalement, vous devez d'abord deviner. Vous devez deviner la taille appropriée des données et vous devez deviner où se trouvait la corruption des données. Mais vous pouvez toujours utiliser la méthode de la bissection pour vous aider.Dans le commentaire ci-dessous, je pensais que j'étais supposé 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, le
seek
devait montrer qu'à l'étape "afficher le résultat", le décalage1000
se produisait simplement dans le deuxième secteur des données. Si le secteurseek
est 2038399, la corruption est au secteur 2038400e.la source
bs=4194304 count=40
lors de la lecture,/dev/urandom
maisbs=4096 count=40960
lors de l'écriture et de la lecture sur la carte SD? (Ils sont mathématiquement équivalents; 167772160 octets chacun.)seek
, j'ai donc écrit seulement 1 secteur sur la carte, ce qui économise la quantité de transfert de données. Bien sûr, lors de l'expérimentation, j'ai utilisé un bloc de données plus gros, c'est pourquoi le fichier de données généré est de 160 Mo.sudo dd if=test.orig of=/dev/sde seek=2038399 bs=4096
. Et évidemment vous avez raison; il utiliseseek
. Et, oui, techniquement, ça n'utilise pascount
. … (Suite)count
spécification,dd
transfère la totalité de l'entrée (c'est-à-dire qu'elle transfère jusqu'à EOF ou une erreur). Cette commande transfère donc tout le contenu detest.orig
, soit 40960 enregistrements de 4096 octets chacun, pour un total de 167772160 octets (comme je l'ai dit).Tout d'abord, lisez la réponse F3 de @Radtoo. C'est la bonne façon.
Je l'ai en quelque sorte raté et j'ai essayé à ma façon:
créer un fichier de test de 1 Go:
dd if=/dev/urandom bs=1024k count=1024 of=testfile1gb
écrire des copies de ce fichier sur sdcard (64 est la taille de la sdcard en Go):
for i in $(seq 1 64); do dd if=testfile1gb bs=1024k of=/media/sdb1/test.$i; done
vérifier md5 des fichiers (tous sauf le dernier, incomplets, doivent correspondre):
md5sum testfile1gb /media/sdb1/test.*
la source
Le moyen le plus simple de tester la pleine capacité d'une carte SD est de la remplir de fichiers, puis de 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 hachage dans un fichier, puis vérifier qu'ils sont corrects.
Comme l'a souligné @Earthy Engine , 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 les lisent, sont trompées par de fausses cartes SSD.
la source
J'ai écrit un petit script qui fait ce qui suit.
- crée un répertoire temporaire sur la carte USB ou SC cible
- crée un fichier de référence généré aléatoirement de 5 Mo avec la somme de contrôle md5sum -copie le fichier de référence sur la cible et génère une vérification de somme md5 à partir de la cible pour confirmer la réussite de la lecture / écriture -remplit la cible à sa capacité (100%) ou s'arrête lorsqu'une erreur de somme de contrôle se produit -une fois que le script s'arrête naturellement, il affiche la taille cible déclarée, les montants utilisés et gratuits.Avec ce script, j'ai conclu que j'ai été arnaqué par un vendeur ebay qui a passé un microSD de 8 Go pour un 64 Go
la source
On peut écrire une séquence de nombres (chaque ligne fait 16 octets) puis vérifier le contenu:
Vérifiez ensuite la sortie skip == (en utilisant un petit échantillon de valeurs skip qui sont un plus petit nombre d'enregistrements écrits), par exemple skip = 9876 :
Ou, faites un échantillon de 20 emplacements avec un revêtement:
of=tempFileOnSD
, si vous voulez éviter de détruire les données stockées sur votre carte (pertinent uniquement si ce n'est pas un faux)la source
seq -w 0 123456789012345 > /dev/yourSdHere
etseq -w 0 123456789012345 | cmp - /dev/yourSdHere
?