Существует ли способ определить оптимальное значение для параметра bs для dd?

Изредка я встречал комментарии в интернете с призывом “не забудьте установить ‘bs=’ потому что значение по умолчанию займет слишком много времени”, и мои собственные крайне ненаучные наблюдения о том, “ну, похоже, это заняло больше времени, чем в другой раз на прошлой неделе”, подтверждают это. Так что всякий раз, когда я использую “dd” (обычно в диапазоне 1-2 ГБ), я обязательно указываю параметр bytes. Примерно в половине случаев я использую значение, указанное в любом онлайн-руководстве, откуда я копирую; в остальные разы я выбираю какое-то число, которое имеет смысл из списка ‘fdisk -l’ для того, что я предполагаю является более медленной медиа (например, SD-карта, на которую я записываю).

Для данной ситуации (тип носителя, размеры шины или что-либо еще, что имеет значение) есть ли способ определить “лучшее” значение? Это легко определить? Если нет, существует ли простой способ приблизиться к 90-95% результата? Или “просто выбери что-то большее 512” является даже правильным ответом?

Я думал попробовать провести эксперимент сам, но (в дополнение к тому, что это будет большой труд) я не уверен, какие факторы влияют на ответ, поэтому не знаю, как спроектировать хороший эксперимент.

Существует только один способ определить оптимальный размер блока, и это бенчмарк. Я только что провел быстрый бенчмарк. Тестовая машина — это ПК с Debian GNU/Linux, с ядром 2.6.32 и coreutils 8.5. Оба файловых системы являются ext3 на LVM-томах на разделе жесткого диска. Исходный файл имеет размер 2 ГБ (2040000 кБ, если быть точным). Кэширование и буферизация включены. Перед каждым запуском я очищал кэш с помощью sync; echo 1 >|/proc/sys/vm/drop_caches. Время выполнения не включает финальный sync для сброса буферов; последний sync занимает около 1 секунды.

same – это копии на одной и той же файловой системе; diff – это копии на файловую систему на другом жестком диске. Для последовательности времени, сообщенные времена являются временными метками, полученными с помощью утилиты time, в секундах. Я запускаал каждую команду только один раз, поэтому не знаю, насколько велика изменчивость в измерениях времени.

             same   diff
             t (с)  t (с)
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

Вывод: Большой размер блока (несколько мегабайт) помогает, но не драматически (намного меньше, чем я ожидал для копий на одном диске). И cat и cp не работают так уж плохо. С этими цифрами, я не вижу смысла использовать dd. Используйте cat!

dd появился в то время, когда необходимо было переводить старые ленты IBM mainframe, и размер блока должен был соответствовать тому, который использовался для записи ленты, иначе блоки данных могли быть пропущены или укорочены. (9-дорожечные ленты были капризными. Будьте рады, что они давно мертвы.) В наши дни размер блока должен быть кратен размеру сектора устройства (обычно 4 КБ, но на очень новых дисках может быть намного больше, а на очень маленьких флеш-накопителях – меньше, но 4 КБ является разумным золотой серединой вне зависимости) и чем больше, тем лучше для производительности. Я часто использую размер блока 1 МБ для жестких дисков. (У нас тоже есть намного больше памяти в распоряжении сейчас.)

Я согласен с ответом geekosaur, что размер должен быть кратен размеру блока, который часто составляет 4K.

Если вы хотите найти размер блока, stat -c "%o" filename вероятно, самый простой вариант.

Но скажем, вы делаете dd bs=4K, это означает, что он выполняет read(4096); write(4096); read(4096); write(4096)…

Каждый системный вызов включает переключение контекста, что влечет за собой определенные накладные расходы, и в зависимости от планировщика ввода-вывода, чтения с перемежающимися записями могут заставить диск выполнять множество поисков. (Вероятно, это не является большой проблемой с планировщиком Linux, но тем не менее это стоит учесть.)

Таким образом, если вы делаете bs=8K, вы позволяете диску считывать два блока за раз, которые, вероятно, расположены близко друг к другу на диске, прежде чем искать где-то еще для выполнения записи (или для обслуживания ввода-вывода для другого процесса).

По этой логике, bs=16K еще лучше и так далее.

Что мне хотелось бы узнать, есть ли верхний предел, при котором производительность начинает ухудшаться, или это ограничено только объемом памяти.

Как говорит Гиллес, вы можете определить оптимальный параметр для опции bs в dd с помощью бенчмарка. Но это поднимает вопрос: как удобно провести бенчмарк этого параметра?

Мой предварительный ответ на этот вопрос: используйте dd-opt, утилиту, над которой я недавно начал работать, чтобы решить именно эту проблему 🙂

Если нет, есть ли легкий способ приблизиться к 90-95% результата?

Используйте bs=1M

Это даст вам более 96.3% оптимальной производительности на более чем 87% ваших устройств, от медленных USB2/3 флеш-накопителей, SD-карт и жестких дисков до быстрых NVMe Gen3 SSD и даже устройств с только RAM, таких как /dev/zero.

Источник?

Голоса в моей голове.

И некоторые эмпирические испытания на протяжении более 10 лет с помощью dd, комбинированные с псевдонаучным бенчмаркингом и предвзятой здравой логикой.

Эй, вы спросили о легком способе!

Шутки в сторону, bs=1M является хорошим, надежным, беззаботным и универсальным значением по умолчанию, если вы не можете или не хотите тонко настраивать для конкретного сценария или устройства.

Я оптимизировал для sdcard-ридера usb2.0, который, похоже, работает лучше всего при bs=10M. Я пробовал 4k, до 16M, после 8-10M улучшения не было. Вы можете видеть, как измерение скорости передачи ухудшается…скорее всего, из-за загрузки буферов на устройстве, затем ожидания, когда устройство передаст данные на фактические носители.

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 записей во
123+0 записей из
1289748480 байт (1.3 ГБ) скопировано, 21.4684 с, 60.1 МБ/с
341+0 записей во
341+0 записей из
3575644160 байт (3.6 ГБ) скопировано, 117.636 с, 30.4 МБ/с
816+0 записей во
816+0 записей из
8556380160 байт (8.6 ГБ) скопировано, 326.588 с, 26.2 МБ/с
955+0 записей во
955+0 записей из
10013900800 байт (10 ГБ) скопировано, 387.456 с, 25.8 МБ/с