В настоящее время у меня проблемы с dd
вызовом разреженного файла в качестве input ( if
) и файла в качестве output ( of
) с conv=sparse
. dd
похоже, что используется только одно ядро ЦП ( Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz
4 ядра + 4 Intel Hyperthreads) (100% от 1 ядра), поэтому мне было интересно, возможно ли распараллеливание dd
. Я был
- глядя в
info dd
иman dd
и там , кажется , встроенной функции в версии 8.23 corutils - проверка
sgp_dd
изsg3-utils
пакета (не понимая, подходит ли он моим потребностям), но, похоже, он не в состоянии обрабатывать разреженные файлы dcfldd
не похоже на возможности распараллеливания
насколько мне известно
- расширенная версия / ветвь с внутренней обработкой программных частей в нескольких потоках (избегайте изменений контекста, снижающих производительность ввода-вывода) предпочтительнее, чем
- решение с GNU,
parallel
работающим локально, предпочтительнее - пользовательский (возможно, не проверенный) фрагмент кода
Как избежать того, чтобы процессор был узким местом интенсивной операции ввода-вывода? Я хотел бы запустить команду в Ubuntu 14.04 с Linux 3.13 и обрабатывать с ней разреженные образы файловых файлов на любой файловой системе, поддерживающей разреженный файл (по крайней мере, решение не должно быть привязано к одной конкретной файловой системе).
Предыстория: я пытаюсь создать копию разреженного файла размером 11 ТБ (содержащего около 2 ТБ данных) на zfs (нестабильная версия zfsonlinux 0.6.4, возможно, глючит и причина узкого места ЦП (в конечном итоге медленный поиск дырок)). Это ничего не должно изменить в вопросе о том, как распараллелить dd (очень общим способом).
источник
dd
по умолчанию загружает процессор из-за небольшого размера блока. сделать его больше, какbs=1M
.Ответы:
Протестировано в Bash:
Вам, вероятно, нужно настроить 1000.
источник
Подходит один нестандартный, непроверенный фрагмент кода:
Это должно логически разделить файл на четыре блока по 3 ТБ и обрабатывать их параллельно. (
skip=
пропускает входные блоки;seek=
ищет выходные блоки.) Четвертая команда, конечно, будет считывать до конца старого файла, поэтомуcount=
параметр не является строго обязательным.источник
conv=notrunc
conv=notrunc
подразумеваетсяseek=
с положительным значением.