13

Я купил карту SD на 64 ГБ у eBay. Он отлично работает, когда я записываю на него образ ARM Arch Linux и использую его для загрузки моего Raspberry Pi.

Однако, когда я пытаюсь создать на нем один раздел ext4 для использования всей емкости карты, возникают ошибки. mkfs.ext4 всегда заканчивается счастливо; тем не менее, раздел не может быть mount ed, всегда выдает ошибку, и dmesg показывает, что сообщения ядра включают в себя « Cannot find journal . Это подтвердилось как минимум на двух платформах: Arch Linux ARM и Ubuntu 13.04.

С другой стороны, я могу создать и смонтировать раздел FAT32 без ошибок (проверка полной емкости не была выполнена).

Я слышал, что некоторые плохие парни могут изменить интерфейс SD-карты, чтобы сообщить о неправильной емкости ОС (т. Е. Карта действительно всего 2 ГБ, но сообщает о себе как 64 ГБ), чтобы продать карту по более выгодной цене.

Я знаю, что такие инструменты, как badblocks существуют для того, чтобы проверять SD-карту на наличие плохих блоков. Могут ли badblocks обнаруживать подобные проблемы? Если нет, то какие еще существуют решения для тестирования карты?

В идеале я хотел бы знать, был ли я обманут или нет; если результат показывает, что я только что получил плохой товар, я могу только вернуться к продавцу, а сообщить в eBay, что кто-то пытался меня обмануть.

ОБНОВИТЬ

операции и сообщения:

~$ 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

ОБНОВИТЬ

Я запустил badblocks /dev/sde но он не сообщает об ошибке. Это означает, что оставшиеся причины:

  • SD-машина хороша, но по какой-то причине mke2fs или mount или kernel имеют ошибку, которая вызывает проблему.

  • Меня обманули таким образом, что badblocks не могут обнаружить поражение. Это правдоподобно, потому что я думаю, что badblocks просто выполняет некоторый тест записи-чтения на месте. Однако мошенник может связать доступ к исходящим областям с некоторым входящим блоком. В этом случае проверка на запись-чтение на месте не может обнаружить проблему.

Если нет приложения, способного выполнить надлежащий тест, я думаю, что я могу попытаться написать простую C-программу для его тестирования.

5 ответов5

22

Если кто-то увидит это позже: кто-то написал инструмент с открытым исходным кодом под названием "F3" для проверки емкости SD-карт и других подобных носителей. Его можно найти на проекте hompage и в Github.

4

Обман был подтвержден следующими шагами:

  • Создайте файл случайных данных. (4194304 = 4 * 1024 * 1024 = 4 МБ, общий размер = 40 * 4 МБ = 160 МБ)

Команда:

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
  • Скопируйте данные на SD-карту. (2038340 * 4096 = 8153600 КБ = 7962,5 МБ)

Команда:

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
  • Считать данные с SD-карты обратно.

Команда:

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
  • Показать результат

Команда:

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

...

Что происходит? мы наблюдали разрыв нулей. Это показатель того, что случайные данные фактически не были записаны на карту. Но почему после 128100 данные возвращаются? Очевидно, карта имеет внутренний кэш.

Мы также можем попытаться исследовать поведение кэша.

hexdump test.orig | grep ' 0000 0000 '

не дает результата, что означает, что сгенерированный мусор не имеет такой картины. Тем не мение,

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

есть 4 матча.

Вот почему он проходит badblocks наличие бадблоков . Дальнейшее тестирование может показать, что фактическая емкость составляет 7962,5 МБ или 8 ГБ.

Я пришел к выводу, что это очень маловероятно, просто случайный сбой оборудования, но вид обмана. Я хотел бы знать, какие действия я могу предпринять, чтобы помочь другим жертвам.

2

Прежде всего, прочитайте ответ F3 от @Radtoo. Это правильный путь.

Я как-то пропустил это и попробовал по-своему:

  1. создать тестовый файл 1 ГБ : dd if=/dev/urandom bs=1024k count=1024 of=testfile1gb

  2. записать копии этого файла в SDCard (64 - размер SDCard в ГБ): for i in $(seq 1 64); do dd if=testfile1gb bs=1024k of=/media/sdb1/test.$i; done

  3. проверьте md5 файлов (все, кроме последнего, неполного, должны совпадать): md5sum testfile1gb /media/sdb1/test.*

1

Я написал небольшой скрипт, который делает следующее.

-создание временного каталога на целевую карту USB или SC

- Создает случайно сгенерированный контрольный файл объемом 5 МБ с помощью контрольной суммы md5. - Копирует контрольный файл в цель и генерирует проверку md5sum из цели для подтверждения успешного чтения / записи. - Заполняет цель до емкости (100%) или останавливается, когда возникает ошибка контрольной суммы. - как только сценарий останавливается естественным образом, он отображает целевой размер сообщения, использованные и свободные суммы.

С помощью этого скрипта я пришел к выводу, что меня сорвал продавец eBay, который передал 8 ГБ microSD за 64 ГБ

#!/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
1

Самый простой способ проверить полную емкость SD-карты - это заполнить ее файлами, а затем проверить правильность файлов: diff -qr /directory/on/computer /directory/on/SD

В качестве альтернативы вы можете использовать программы для записи шаблонов или цепочек хэшей в файл, а затем проверять их правильность.

Как отметил @Earthy Engine , важно заполнить SD-карту, а затем прочитать данные, поскольку традиционные подходы, которые просто записывают небольшой блок данных, а затем читают его, одурачены поддельными картами SSD.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .