Отформатируйте usb и подтвердите все нули

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

sudo apt-get install scrub

scrub поддерживает множество различных типов скрубберных паттернов

Available patterns are:
  nnsa          3-pass   NNSA NAP-14.1-C
  dod           3-pass   DoD 5220.22-M
  bsi           9-pass   BSI
  usarmy        3-pass   US Army AR380-19
  random        1-pass   One Random Pass
  random2       2-pass   Two Random Passes
  schneier      7-pass   Bruce Schneier Algorithm
  pfitzner7     7-pass   Roy Pfitzner 7-random-pass method
  pfitzner33   33-pass   Roy Pfitzner 33-random-pass method
  gutmann      35-pass   Gutmann
  fastold       4-pass   pre v1.7 scrub (skip random)
  old           5-pass   pre v1.7 scrub
  dirent        6-pass   dirent
  fillzero      1-pass   Quick Fill with 0x00
  fillff        1-pass   Quick Fill with 0xff
  custom        1-pass   custom="string" 16b max, use escapes \xnn, \nnn, \\

Чтобы использовать [ f7], чтобы заполнить диск всеми zeros, сначала убедитесь, что привод не установлен. Затем запустите следующую строку (-p означает шаблон для использования):

sudo scrub -p fillzero /dev/sdX

, тогда вы должны увидеть что-то вроде этого:

scrub: using Quick Fill with 0x00 patterns
scrub: please verify that device size below is correct!
scrub: scrubbing /dev/sdh 31260704768 bytes (~29GB)
scrub: 0x00    |.....                                           |

Некоторые шаблоны, используемые для очистки должен иметь пропуск verify, чтобы убедиться, что очистка прошла.

Если вы хотите, вы можете добавить hexdump (как в ответе Байтодера) или любой другой ответ до конца для проверка!

надеюсь это поможет!

Используя cmp (спасибо муру за то, что указали глупость использования трубы):

sudo cmp /dev/zero /dev/sdX

Если вы получите такой вывод, как этот:

cmp: EOF on /dev/sdX

Привод заполнен нулем.

% dd if=/dev/zero of=foo iflag=fullblock bs=1M count=1 && sync
1+0 records in
1+0 records out
1048576 bytes (1,0 MB) copied, 0,00226603 s, 463 MB/s
% cmp /dev/zero foo
cmp: EOF on foo

Мое предложение было бы hexdump. Он отображает содержимое любого файла или устройства в шестнадцатеричном формате в виде строк по 16 байт, но если две подпоследовательные строки равны, он их пропускает.

Ниже приведен пример вывода файла 512 МБ virtualdevice, который заполняется нулями только в текущем каталоге моего жесткого диска. Самый левый столбец - это смещение строки в шестнадцатеричной нотации, 8 следующих столбцов - это фактические данные, сгруппированные в два байта (4 шестнадцатеричных символа):

$ hexdump ./virtualdevice 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
20000000

Производительность :

Я приложил усилия и сравнил свое решение с остальными реальным временем выполнения и временем процессора для описанного файла примера (512 МБ, содержащего только двоичные нули, расположенные на HDD).

Я измерил каждое решение командой time два раза со свежеочищенным дисковым кэшем и два раза с уже кэшированным файлом. Имена времени равны именам команды time, а дополнительная строка CPU - это просто сумма USER + SYS раз. Это может превышать время REAL, потому что я запускаю двухъядерную машину.

Для большинства людей интересными цифрами являются REAL (время от начала до конца, как если бы измерено с помощью секундомера .

Сводка:

Наилучшая производительность имеет [[dd]]

d8] Резюме: оптимизированная вторая версия (grep -zq . DEVICE), которая использует невероятно малое время обработки процессора. Доля 2-го уровня cmp /dev/zero DEVICE (оптимизированное решение kos) и мое собственное решение hexdump DEVICE. Между ними почти нет разницы. Для передачи данных с dd на cmp ([unftimized solution] dd if=/dev/zero | cmp - DEVICE - kos не очень эффективно, трубопровод, кажется, потребляет много времени обработки. Использование dd и grep показывает наихудшую производительность тестируемых команд.

kos

Хотя наиболее важной частью таких операций является время доступа ввода-вывода, существуют значительные различия в скорости обработки и эффективности тестируемых

Если вы очень нетерпеливы, используйте вторую версию ответа муру (grep -zq . DEVICE)! Но вы также можете использовать либо вторую версию kos 'ответ (cmp /dev/zero DEVICE) или мой собственный (hexdump device), так как они имеют почти хорошую производительность. Однако мой подход имеет то преимущество, что вы сразу видите содержимое файла и можете приблизиться к тому, сколько байтов отличается от нуля и где они находятся. Если у вас много переменных данных, выход будет большим, и он, вероятно, будет замедляться.

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

. Еще раз обратите внимание, что тест был выполнен в файле на моем диске, а не в фактическое устройство. Также файл содержит только нули.

muru

        |    Uncached:      |    Cached:
 Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
--------+-------------------+------------------
   REAL |  7.689s   8.668s  |  1.868s   1.930s
   USER |  1.816s   1.720s  |  1.572s   1.696s
    SYS |  0.408s   0.504s  |  0.276s   0.220s
    CPU |  2.224s   2.224s  |  1.848s   1.916s

        |    Uncached:      |    Cached:
 Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
--------+-------------------+------------------
   REAL |  9.434s  11.004s  |  8.802s   9.266s
   USER |  2.264s   2.364s  |  2.480s   2.528s
    SYS | 12.876s  12.972s  | 12.676s  13.300s
    CPU | 15.140s  15.336s  | 15.156s  15.828s

        |    Uncached:      |    Cached:
 Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
--------+-------------------+------------------
   REAL |  8.763s   6.485s  |  0.770s   0.833s
   USER |  0.644s   0.612s  |  0.528s   0.544s
    SYS |  0.440s   0.476s  |  0.236s   0.264s
    CPU |  1.084s   1.088s  |  0.764s   0.808s

        |    Uncached:      |    Cached:
 Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
--------+-------------------+------------------
   REAL |  7.678s   6.539s  |  3.151s   3.147s
   USER |  2.348s   2.228s  |  2.164s   2.324s
    SYS |  3.672s   3.852s  |  3.792s   3.516s
    CPU |  6.020s   6.080s  |  5.956s   5.840s

        |    Uncached:      |    Cached:
 Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
--------+-------------------+------------------
   REAL |  6.340s   9.183s  |  1.660s   1.660s
   USER |  1.356s   1.384s  |  1.216s   1.288s
    SYS |  0.640s   0.596s  |  0.428s   0.360s
    CPU |  1.996s   1.980s  |  1.644s   1.648s

Используемые команды: [ ! d43]

Для всех четырех тестов я дважды выполнил следующую процедуру, чтобы уменьшить неточности, заменив <COMMAND> на точную команду из заголовка каждой таблицы.

        |    Uncached:      |    Cached:
 Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
--------+-------------------+------------------
   REAL |  7.689s   8.668s  |  1.868s   1.930s
   USER |  1.816s   1.720s  |  1.572s   1.696s
    SYS |  0.408s   0.504s  |  0.276s   0.220s
    CPU |  2.224s   2.224s  |  1.848s   1.916s

time <COMMAND>

        |    Uncached:      |    Cached:
 Time:  |  Run 1:   Run 2:  |  Run 1:   Run 2:
--------+-------------------+------------------
   REAL |  9.434s  11.004s  |  8.802s   9.266s
   USER |  2.264s   2.364s  |  2.480s   2.528s
    SYS | 12.876s  12.972s  | 12.676s  13.300s
    CPU | 15.140s  15.336s  | 15.156s  15.828s