it-swarm-ru.tech

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

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

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

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

74
user4443

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

29
geekosaur

Есть только один способ определить оптимальный размер блока, и это эталонный тест. Я только что сделал быстрый тест. Тестовая машина - это ПК с 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 (s)  t (s)
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!

61
Gilles 'SO- stop being evil'

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

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

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

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

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

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

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

8
Mikel

Как говорит Жиль, вы можете определить оптимальный параметр для bs опции dd путем сравнительного анализа. Это, однако, вызывает вопрос: как вы можете удобно сравнить этот параметр?

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

5
sampablokuper

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

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s
0
wwright