Как рассчитать оптимальный размер блока при запуске dd
? Я немного исследовал это и не нашел ничего, что подсказывало бы, как это можно сделать.
У меня сложилось впечатление, что чем больше размер блока, тем быстрее dd
... это правда?
Я собираюсь использовать dd
два идентичных жестких диска Hitachi емкостью 500 ГБ, которые работают со скоростью 7200 об / мин на коробке с Intel Core i3 с 4 ГБ DDR3 1333 МГц RAM, поэтому я пытаюсь выяснить, какой размер блока использовать. (Я собираюсь загрузить Ubuntu 10.10 x86 с флеш-накопителя и запустить его с него.)
dd
нахождения оптимального размера блока при передаче файлаОтветы:
Оптимальный размер блока зависит от различных факторов, включая операционную систему (и ее версию), а также различные задействованные аппаратные шины и диски. Несколько Unix-подобных систем (включая Linux и, по крайней мере, некоторые разновидности BSD) определяют
st_blksize
член в классе,struct stat
который дает то, что ядро считает оптимальным размером блока:Лучше всего поэкспериментировать: скопировать гигабайт с разными размерами блока и временем этого. (Не забывайте очищать кеш буфера ядра перед каждым запуском :)
echo 3 > /proc/sys/vm/drop_caches
.Однако, как показывает опыт, я обнаружил, что достаточно большой размер блока позволяет
dd
хорошо выполнять свою работу, а разница между, скажем, 64 КиБ и 1 МиБ незначительна, по сравнению с 4 КиБ против 64 КиБ. (Хотя, по общему признанию, прошло много времени с тех пор, как я это сделал. Сейчас я использую мебибайт по умолчанию или просто позволяюdd
выбирать размер.)источник
Как говорили другие, не существует универсально правильного размера блока; что оптимально для одной ситуации, или одно оборудование может быть ужасно неэффективным для другой. Кроме того, в зависимости от состояния дисков может быть предпочтительнее использовать размер блока, отличный от «оптимального».
Одна вещь, которая является довольно надежной на современном оборудовании, заключается в том, что размер блока по умолчанию в 512 байтов, как правило, почти на порядок медленнее, чем более оптимальная альтернатива. Если вы сомневаетесь, я обнаружил, что 64K - довольно надежный современный стандарт по умолчанию. Хотя 64 КБ обычно не является оптимальным размером блока, по моему опыту, он имеет тенденцию быть намного более эффективным, чем значение по умолчанию. 64K также имеет довольно солидную историю надежной производительности: вы можете найти сообщение в списке рассылки Eug-Lug, примерно в 2002 году, рекомендующее размер блока 64K здесь: http://www.mail-archive.com/eug- lug@efn.org/msg12073.html
Для определения оптимального размера выходного блока я написал следующий скрипт, который тестирует запись 128-мегабайтного тестового файла с dd в диапазоне различных размеров блока, от 512 байт по умолчанию до 64 мегабайт. Имейте в виду, что этот скрипт внутренне использует dd, поэтому используйте его с осторожностью.
dd_obs_test.sh:
Посмотреть на GitHub
Я тестировал этот сценарий только в системе Debian (Ubuntu) и OSX Yosemite, поэтому, вероятно, потребуется некоторая настройка, чтобы он работал с другими версиями Unix.
По умолчанию команда создаст тестовый файл с именем dd_obs_testfile в текущем каталоге. В качестве альтернативы вы можете указать путь к пользовательскому файлу теста, указав путь после имени скрипта:
Результатом скрипта является список протестированных размеров блоков и их соответствующих скоростей передачи, например:
(Примечание: единицы скорости передачи зависят от ОС)
Чтобы проверить оптимальный размер блока чтения, вы можете использовать более или менее тот же процесс, но вместо чтения из / dev / zero и записи на диск вы должны читать с диска и писать в / dev / null. Скрипт для этого может выглядеть так:
dd_ibs_test.sh:
Посмотреть на GitHub
Важным отличием в этом случае является то, что тестовый файл - это файл, записываемый сценарием. Не указывайте этой командой существующий файл, иначе существующий файл будет перезаписан нулями!
Для моего конкретного оборудования я обнаружил, что 128 КБ был наиболее оптимальным размером входного блока на жестком диске, а 32 КБ был наиболее оптимальным для SSD.
Хотя этот ответ охватывает большинство моих выводов, я сталкивался с этой ситуацией достаточно раз, чтобы написать об этом сообщение в блоге: http://blog.tdg5.com/tuning-dd-block-size/ Вы можете найти больше подробностей о тестах, которые я там проводил.
источник
dd_obs_test.sh
conv=fsync
не работает на macOS и может быть удален.Я обнаружил, что мой оптимальный размер блока составляет 8 МБ (равный кешу диска?). Мне нужно было стереть (некоторые говорят: промыть) пустое пространство на диске перед созданием его сжатого изображения. Я использовал:
Я экспериментировал со значениями от 4K до 100M.
После того, как dd поработал какое-то время, я убил его (Ctrl + C) и прочитал вывод:
Поскольку dd отображает скорость ввода / вывода (в данном случае 19,1 МБ / с), легко увидеть, работает ли выбранное вами значение лучше, чем предыдущее, или хуже.
Мои оценки:
Примечание. Чтобы проверить размер вашего дискового кеша / буфера, вы можете использовать
sudo hdparm -i /dev/sda
источник
8M
это сложно превзойти.Это полностью зависит от системы. Вам следует поэкспериментировать, чтобы найти оптимальное решение. Попробуйте начать с
bs=8388608
. (Поскольку жесткие диски Hitachi имеют кэш 8 МБ.)источник
bs=8M
на GNU / Linux илиbs=8m
на BSDbs=8388608
иисточник
источник