Вопросы Теги

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

Обычно необходимо использовать kill (короткий для kill -s TERM, или в большинстве систем kill -15) прежде kill -9 (kill -s KILL) для давания цели обрабатывают шанс вымыться после себя. (Процессы не могут поймать или проигнорировать SIGKILL, но они могут и часто ловить SIGTERM.), Если Вы не даете процессу шанс закончить то, что он делает и очищает, он может оставить поврежденные файлы (или другое состояние), вокруг которого он не сможет понять когда-то перезапущенный.

strace/truss, ltrace и gdb обычно хорошие идеи для взгляда на то, почему застревает застрявший процесс. (truss -u на Солярисе особенно полезно; я нахожу ltrace слишком часто аргументы подарков библиотеке звонят в неприменимый формат.) Солярис также имеет полезный /proc- основанные инструменты, некоторые из которых были портированы к Linux. (pstack часто полезно).

72
18.03.2011, 00:44
5 ответов

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

27
27.01.2020, 19:31
  • 1
    или устройства массового хранения USB являются или 512 или 4 096 (более новыми) байтами. Медиа флэш-памяти оптического и прямого доступа составляют 2 048 байтов. Не может пойти не так, как надо с 4 096 байтами. –  LawrenceC 17.03.2011, 15:34
  • 2
    Почему размер блока программы копирования должен иметь какое-либо отношение к характеристикам базового устройства (исключенные ленты)? Ядро делает свою собственную буферизацию (и иногда упреждающая выборка) так или иначе. –  Gilles 'SO- stop being evil' 18.03.2011, 00:43
  • 3
    Минимизировать дробные буферы; дела в целом идут быстрее при использовании выровненных буферов, потому что ядро может запустить буферные чтения/записи в секторе (или лучше, дорожка или цилиндр, но я думаю современная ложь дисков о них) и буферные границы ядра, потому что ядро не должно перескакивать через материал или считать дополнительный материал или управлять частичными буферами. Конечно, можно просто позволить ядру иметь дело со всем этим, но если Вы копируете гигабайты данных, что дополнительная работа может значительно сократить время копии. –  geekosaur 18.03.2011, 00:53
  • 4
    (Обычно) необходимо включать @Gilles если Вы хотите, чтобы я был уведомлен относительно Вашего ответа комментария, посмотрите, Как действительно комментируют работу @replies?. Так как я, оказалось, проходил мимо: ядро будет иметь дело со всем этим так или иначе. Ваше заявление, которое, “что дополнительная работа может значительно сократить время копии”, не соглашается с моими сравнительными тестами, но различными системами, может иметь различные поведения, поэтому внесите синхронизации также! –  Gilles 'SO- stop being evil' 18.03.2011, 01:07
  • 5
    @Gilles: извините, я принял Вас за исходного автора вопроса. –  geekosaur 18.03.2011, 01:09

Существует всего лишь один способ определить оптимальный размер блока, и это - сравнительный тест. Я только что сделал быстрый сравнительный тест. Тестовой машиной является ПК, выполняющий 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
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
27.01.2020, 19:31
  • 1
    я рекомендовал бы OP сделать его собственное сравнительное тестирование, но так или иначе, хороший ответ! –  ninjalj 18.03.2011, 01:00
  • 2
    @Nikhil >| совпадает с > за исключением того, что под set -o noclobber, оболочка будет жаловаться, что файл существует, если Вы используете >. –  Gilles 'SO- stop being evil' 23.12.2011, 23:29
  • 3
    @Masi Да, если я хочу клонировать целый диск, я буду использовать cat. Почему Вы ищете лучший путь? Что случилось с cat? –  Gilles 'SO- stop being evil' 11.05.2016, 14:05
  • 4
    @Masi cat просто копирует его вход в его вывод. Если Вы хотите скопировать с ненадежных медиа и перескочить через нечитабельные части или повторную попытку многократно, это - другая проблема, для который ddrescue работы довольно приятно. –  Gilles 'SO- stop being evil' 11.05.2016, 15:52
  • 5
    @sudo можно было скопировать объем данных с lsof. Мгновенная скорость не очень релевантна с дисковой копией, потому что это универсально, таким образом, можно разделить байты, переданные прошедшим временем; если Вы хотите что-то лучше, можно использовать pv. –  Gilles 'SO- stop being evil' 06.05.2017, 21:36

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

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

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

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

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

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

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

8
27.01.2020, 19:31
  • 1
    , не размышляйте! –  Gilles 'SO- stop being evil' 18.03.2011, 01:30
  • 2
    Интерфейс программирования Linux соглашается со мной. См. Главу 13 - Буферизация Файлового ввода-вывода. помещение –  Mikel 18.03.2011, 03:13
  • 3
    Интересно, их сравнительные тесты предполагают, что выше 4K существует мало преимущества как бы то ни было. –  Mikel 18.03.2011, 03:24
  • 4
    Кроме того, по-видимому, чтение файла по умолчанию вперед окно составляет 128 КБ, так, чтобы значение могло бы быть выгодным. использование –  Mikel 18.03.2011, 03:33
  • 5
    у меня есть доступ к 24 дискам RAID50 здесь, где bs=8K получает меня 197MB/s, но bs=1M получает меня 2,2 ГБ/с, который является близко к теоретической пропускной способности RAID. Таким образом, бакалавр наук имеет БОЛЬШОЕ ЗНАЧЕНИЕ. Однако с помощью bs=10M я только получаю 1.7GB/s. Таким образом, это, кажется, ухудшается по некоторому порогу, но не уверенное почему. –  Joseph Garvin 02.11.2015, 20:22

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

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

5
27.01.2020, 19:31
  • 1
    Какова чувствительность вывода? 90-95% или> 95%? Я не нахожу, что можно изменить его. –  Léo Léopold Hertz 준영 11.05.2016, 11:54
  • 2
    @Masi, я боюсь, что не продолжил работать dd-opt в долгое время. Однако это - бесплатное программное обеспечение, лицензируемое под AGPLv3. Так, не стесняйтесь улучшать его и до evalutate его чувствительность/точность! –  sampablokuper 11.05.2016, 14:17

Я оптимизировал для устройства чтения 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
27.01.2020, 19:31

Теги

Похожие вопросы