How can I test the full capacity of an SD card in Linux?
I purchased a 64 GB SD card from eBay. It works fine when I burn an Arch Linux ARM image to it and use it to boot up my Raspberry Pi. However, when I try to create a single ext4 partition on it to use all capacity of the card, errors occur. mkfs.ext4 always finishes happily; however, the partition cannot be mount ed, always throwing an error and dmesg shows kernel messages includes Cannot find journal . This has proved to be the case on at least two platforms: Arch Linux ARM and Ubuntu 13.04. On the other hand, I can create and mount a FAT32 partition without error (a full capacity check has not been done). I heard that some bad guys can change the SD card interface to report a wrong capacity to the OS (i.e. the card is really only 2 GB but it reports itself as a 64 GB) in order to sell the card at a better price. I know that tools like badblocks exist for me to check the SD card for bad blocks. Can badblocks detect problems like this? If not, what other solutions exist for me to test the card? I’d ideally like to know whether I was cheated or not; if the result shows I just received a bad item, I can return to the seller only, rather report to eBay that somebody tried to cheat me. UPDATE operations and 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 - The SD car is good but for some reason mke2fs or mount or the kernel have a bug that causes the problem.
- I was cheated in a way that badblocks that cannot detect the defeat. This is plausible because I think badblocks is just doing some in-place write-read test. However, the cheater can make the access to outbound areas link back to some inbound block. In this case a in-place write-read check is not able to detect the problem.
If there is no application can do the proper test, I think I can try to write a simple C program to test it.
Проверьте реальный размер флэш-накопителя USB
Недавно я много читал о поддельных картах MicroSD и флэш-накопителях USB, которые утверждают, что имеют много места (даже если вы спрашиваете компьютер), но физически предлагают намного меньше. Я недавно купил USB-накопитель SanDisk (заявлено 128 ГБ) и хочу проверить его размер. Это не куплено через ebay или что-то, но я действительно хочу проверить реальный размер прежде, чем использовать это продуктивно.
Я мог бы просто скопировать материал на него, скопировать обратно и посмотреть, все ли в порядке. Я мог бы также автоматизировать это с помощью хэшей и прочего. Но я надеялся, что есть более точное решение. Я читал, что для Windows H2testw делает свое дело. Есть ли простой способ проверить это на Ubuntu/Linux? Может быть, специализированный, хорошо работающий инструмент?
Обновление: просто чтобы прояснить, идея состоит в том, чтобы проверить, что размер, который система Linux сообщает контроллеру, является правильным (поэтому никакие данные не будут потеряны). Я не хочу видеть, получу ли я 128 ГБ вместо 127,3 ГБ. Я хочу проверить, будут ли все записанные мной данные снова доступны для чтения. К сожалению, я могу найти только немного информации об этом на английских технических сайтах. Хотя есть хорошие немецкие источники. На самом деле я ищу приложение, подобное этому, но для Ubuntu / Linux: https://www.raymond.cc/blog/test-and-detect-fake-or-counterfeit-usb-flash-drives-bought-from-ebay-with-h2testw/
Update2: я попытался собрать некоторые источники на английском языке. Я не прочитал все их подробно, из-за нехватки времени.
Обновление 3: объяснения
Из-за странных критиков ниже, некоторые объяснения.
В чем проблема и почему один дд не решает ее?
«Четко определите, какую проблему вы пытаетесь решить, и каково определение» фальшивого драйва «».
Кажется, что некоторые люди не понимают проблему. Поэтому я попытаюсь объяснить это как можно более кратко, хотя я думаю, что это во многом зависит от моего вопроса.
Емкость USB-устройств, которые предоставляет вам ваша операционная система или инструменты Unix, может быть неправильной. Это фатально, так как ваша ОС регулирует объем данных, которые вы можете отправить. Если вы отправите больше данных, чем сможете, вы потеряете данные. Это проблема. Итак, почему это может произойти?
Вам не нужно хорошо знать USB-протокол, чтобы понять проблему. Последовательные интерфейсы имеют общее свойство: клиентскому устройству (USB-накопителю) необходимо сообщать свою собственную емкость через этот последовательный интерфейс. Это означает, что клиентскому устройству нужен собственный контроллер с некоторыми знаниями о назначении устройств и, в данном случае, его емкости. Он также решает, что сделано, когда получает команду на сохранение чего-либо. Если контроллер запрограммирован таким образом, он может просто игнорировать команду или что-то перезаписать данными.
Что это значит? Что бы ни говорили ваши инструменты Unix о емкости диска: это то, о чем инструменты спрашивали у диска, и больше ничего. Вот для чего был изобретен h2testw: он проверяет реальный размер с помощью метода, описанного ниже, и сравнивает его с тем, что говорит накопитель. Если это не то же самое, у вас может быть потеря данных, потому что все ваши общие операции по хранению данных зависят от информации вашей операционной системы, которая просто запрашивает контроллер. Почему просто спросить? Тестирование требует времени и перезаписывает все данные на диске. Поэтому естественно, что операционная система должна полагаться на эту информацию.
Для проверки реальной емкости, такой как h2testw, вы действительно можете использовать dd чтобы записать данные на диск, прочитайте их еще раз и посмотрите, будет ли это то же самое, что вы написали. Совершенно законно. Характер оборудования и привода делают его более сложным. Рассмотрим кеши для записи, например. Вы должны убедиться, что вы не читаете из кэша. Это только один пример того, почему это не так просто, как кажется. Также подумайте, что просто запись нулей означает низкую энтропию информации, которую можно восстановить при чтении. Это просто не так просто в деталях. Вы все еще можете сделать это вручную, конечно.
Но почему, когда вы можете автоматизировать вещи? Почему на работу? f3, как предложено в моем ответе ниже, реализует тонны мыслей многих участников (считают, что это своего рода расширенный h2testw), а также реализует несколько методов с различными компромиссами. Разработчик выяснил хитрости различных фальшивых дисков (подделок), которые они имели под рукой. Поэтому, хотя я понимаю теорию и проблему (по-видимому, поскольку проблемы хорошо объясняются в немецких технических СМИ, но не в англоязычных СМИ), я не претендую на то, что понимаю все, поэтому я упомянул об этом выше. Это просто теория, которую я понимаю, и я скорее программист. Но как студент, изучающий информатику, я понимаю это достаточно хорошо, чтобы увидеть проблему.
«Попытайтесь понять основные утилиты Unix»
На самом деле я уже ответил на этот вопрос, но чтобы прояснить: инструменты Unix просто используют USB-протокол (конечно, только для USB-устройств) для сбора информации. Нет смысла делать больше, чем это.
Помогает ли покупать только у поставщиков трестов?
«Когда речь заходит о покупке товаров, как и о любой форме безопасности, подумайте о том, чтобы найти надежного продавца и покупать диски только у них».
Безопасность (и безопасность) не о доверии! Речь идет о проверке и валидации! Извините, но это так неправильно во многих отношениях.
Предположим, вы покупаете через доверенного продавца. Несколько вопросов:
- Проверил ли поставщик оборудование, чтобы убедиться в отсутствии потери данных? Узнает ли он, когда он покупает поддельные диски и продает их? Не обязательно.
- Возможно ли, что он покупает вещи, которые он не знает, подделка? В общем, посмотрите на недавние подделки рызенов: https://www.pcgamer.com/beware-of-fake-ryzen-processors-selling-on-amazon/, https://www.heise.de/newsticker/meldung/Direkt-von-Amazon-Faelschungen-von-AMDs-Ryzen-Prozessoren-im-Umlauf-3772757.html
- Если я потеряю свою презентацию в дисководе и испорчу презентацию, вернется ли мой проверенный поставщик вовремя и спасет меня? Это, вероятно, заменит двигатель, так как последний путешествующий во времени DeLorean был разрушен в 1885 году.
Другие вещи
«Этот вопрос действительно больше похож на» промо «в том, что нравится OP, и кажется, что OP гораздо меньше заинтересован в реальном тестировании накопителей».
Это нелепо. Я искал специально подобный инструмент для h2testw, который также работает на Linux. И да, это то, что я «хотел бы», полезный ответ, извините. Я понятия не имел, что англоязычная пресса не слишком осведомлена о таких проблемах, и мне посчастливилось найти что-то подобное позже. Это не промо, но на самом деле вы можете использовать его.