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, \\

Для использования scrub для заполнения диска всем 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 (как в ответе Командующего Байта) или любой из других ответов до конца для проверки.

Hope это помогает!

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

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 МБ, содержание только двоичного файла обнуляет, расположенный на жестком диске).

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

Для большинства людей интересные числа REAL (время от начинает заканчиваться, как будто измеренный с секундомером. Это также содержит IO, ожидают и процессорное время других процессов), и CPU (Процессорное время, которое на самом деле занято командой).

Сводка:

Лучшая производительность имеет оптимизированную вторую версию muru (grep -zq . DEVICE) который использует невероятно несколько времени обработки ЦП.
Оцените 2 доли cmp /dev/zero DEVICE (оптимизированное решение Коса) и мое собственное решение hexdump DEVICE. Нет почти никакого различия между ними.
Передавать данные по каналу из dd кому: cmp (dd if=/dev/zero | cmp - DEVICE - неоптимизированное решение Коса), очень неэффективно, передача по каналу, кажется, использует много времени обработки.
Используя dd и grep показывает далеким худшим выполнением протестированных команд.

Заключение:

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

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

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

Также обратите внимание снова, что тест был сделан на файле на моем диске вместо существующего устройства. Также файл содержал, только обнуляет. Оба влияния действия.

Вот подробные результаты:

• hexdump ./virtualdevice (мое собственное решение):

          |    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
  

• dd if=./virtualdevice | grep -zq . && echo non zero (неоптимизированное решение muru):

          |    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
  

• grep -zq . ./virtualdevice && echo non zero (оптимизированное решение muru):

          |    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
  

• dd if=/dev/zero | cmp - ./virtualdevice (неоптимизированное решение Коса):

          |    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
  

• cmp /dev/zero ./virtualdevice (оптимизированное решение Коса):

          |    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
  

Команды использовали:

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

• Позвольте ядру отбросить все дисковые кэши:

  sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
  

• Сначала синхронизированное (некэшируемое) выполнение, файл загружается в кэш во время этого:

  time <COMMAND>
  

• Второе синхронизированное выполнение (кэшируется). На этот раз большинство данных взято от дискового кэша в RAM, поэтому это намного быстрее, получая доступ к диску непосредственно:

  time <COMMAND>