Я хочу отформатировать свой usb-накопитель и убедиться, что он заполнен нулями. Для форматирования я использую следующую команду:
sudo mkfs.vfat -I /dev/sdb
Как убедиться, что устройство заполнено нулями через командную строку?
решение1
Я тоже подниму свою шляпу на ринг. Одна из альтернатив, которую я люблю использовать, это 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) или любой другой ответ в конец для проверки.
Надеюсь это поможет!
решение2
Подайте заявку ddи trдля виртуального осмотра:
dd if=/dev/sdb | tr '\0' 0
Подать заявку ddи grepдля автоматической проверки:
dd if=/dev/sdb | grep -zq . && echo non zero
Вышеприведенный пример значительно медленнее оптимизированной команды ниже:
grep -zq . /dev/sdb && echo non zero
grep -zчитает строки, разделенные нулем. Если все байты нулевые, то каждая строка пустая, поэтому .никогда не должна совпадать.
Конечно, это не будет справедливо для отформатированного раздела — система форматирования будет использовать некоторые байты, и они будут ненулевыми.
решение3
Я бы предложил 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(время от начала до конца, как будто измеренное секундомером. Сюда также входит ожидание ввода-вывода и время ЦП других процессов) и CPU(время ЦП, фактически занятое командой).
Краткое содержание:
Лучшее выступлениемуруоптимизированная вторая версия ( grep -zq . DEVICE), которая использует невероятно мало процессорного времени.
Доля ранга 2 cmp /dev/zero DEVICE(кос' оптимизированное решение) и мое собственное решение hexdump DEVICE. Между ними почти нет разницы.
Чтобы передать данные из ddв cmp( dd if=/dev/zero | cmp - DEVICE-кос' неоптимизированное решение) очень неэффективно, конвейеризация, похоже, потребляет много времени обработки.
Использование ddи grepпоказывает наихудшую производительность из протестированных команд.
Заключение:
Хотя наиболее важной частью подобных операций является время доступа к вводу-выводу, существуют значительные различия в скорости обработки и эффективности протестированных подходов.
Если вы очень нетерпеливы, используйте вторую версиюмуруответ ( 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.916sdd if=./virtualdevice | grep -zq . && echo non zero(мурунеоптимизированное решение):| 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.828sgrep -zq . ./virtualdevice && echo non zero(муруоптимизированное решение):| 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.808sdd 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.840scmp /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>Второй запуск по времени (кэшированный). На этот раз большая часть данных берется из кэша диска в оперативной памяти, поэтому это намного быстрее, чем при прямом доступе к диску:
time <COMMAND>
решение4
Использование 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