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

7

Я хочу отформатировать мой USB-накопитель и подтвердить, что он заполнен всеми нулями. Для форматирования это команда, которую я использую: sudo mkfs.vfat -I /dev/sdb

Как подтвердить, что устройство заполнено всеми нулями через командную строку?

    
задан homeGrown 17.11.2015 в 14:00
источник

4 ответа

9

Примените dd и tr для виртуального контроля:

dd if=/dev/sdb | tr '
dd if=/dev/sdb | grep -zq . && echo non zero
' 0

Применять dd и grep для автоматической проверки:

grep -zq . /dev/sdb && echo non zero

Вышеуказанное значительно медленнее, чем оптимизированная команда ниже:

%pr_e%

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

Конечно, это не относится к отформатированному разделу - система формата будет использовать некоторые байты, и они будут не нулевыми.

    
ответ дан muru 17.11.2015 в 14:07
источник
11

Я тоже брошу свою шляпу в кольцо. Одна из альтернатив, которую я люблю использовать, - 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 (как в ответе Byte Commander) или любые другие ответы до конца для проверки.

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

    
ответ дан Terrance 17.11.2015 в 14:46
источник
5

Использование 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
    
ответ дан kos 17.11.2015 в 14:27
источник
5

Мое предложение было бы 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 (время от начала до конца, как если бы оно измерялось с помощью секундомера. Это также содержит ожидания ввода-вывода и время процессора других процессов) и CPU (время процессора, которое на самом деле занятой командой).

Резюме:

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

Вывод:

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

Если вы очень нетерпеливы, используйте вторую версию ответа muru ( grep -zq . DEVICE )!
Но вы также можете использовать либо вторую версию ответа kos '( 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 ( kos "не оптимизировано):

            |    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 ( kos ):

            |    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>
    
  • Второй тайм-ход (в кеше). На этот раз большая часть данных берется из дискового кэша в ОЗУ, поэтому он намного быстрее, чем при непосредственном доступе к диску:

    time <COMMAND>
    
ответ дан Byte Commander 17.11.2015 в 15:04
источник

Ознакомьтесь с другими вопросами по меткам