Почему dd занимает слишком много времени?
Трудно сказать, не глядя на страницу руководства. Но, предположив, что ваше руководство отформатировано единообразно, например,
.TP 5
.B \-a
description of \fB\-a\fP option
.TP 5
.B \-b
description of \fB\-b\fP option
и так далее, вы могли бы написать сценарий Perl, чтобы выбрать параметры в следующих абзацах и написать страницу руководства с отсортированными параметрами. (bash и awk кажутся недостаточно мощными для этой задачи, по крайней мере, бесполезны, например, для xterm ).
Если разметка вашей справочной страницы непоследовательна, например, использование разметки для опций, которые можно легко принять за другой описательный элемент, это усложнит сценарий. Но на самом деле, как только он будет отсортирован, вы не будете часто возвращаться к этой задаче, и (если у вас достаточно справочных страниц, чтобы оправдать время, потраченное на сценарий), сценарий можно будет использовать повторно.
Как вариант, вы можете сохранить все параметры в файлах и отсортировать этот список (по имени параметра). Это, конечно, менее элегантно и не очень помогает с возможностью повторного использования.
У кого-то уже может быть многоразовый сценарий; Однако получение последовательного ввода очень помогает.
Много лет назад в стране Unix dd был необходимым способом копирования блочного устройства. Это стало культом карго, хотя (по крайней мере, в системах на базе Linux) cat почти всегда быстрее, чем dd .
Однако даже в прошлом приличный размер блока помог уменьшить количество (медленных) системных вызовов, учитывая, что каждый системный вызов запускал операцию ввода-вывода. Размер блока по умолчанию составляет 512 байт (один сектор диска). Объединение нескольких дисковых блоков в одно чтение было - и остается - также приемлемым. В этом примере используется размер блока 32 МБ:
dd bs=$((512*2048*32)) if=/dev/source of=/dev/target
Однако в современных системах на базе Linux диски могут быть наиболее эффективно скопированы с помощью простого cat
cat /dev/source >/dev/target
(как указано в комментариях к вашему вопросу pv можно заменить на cat , и это даст вам представление о прогрессе и пропускной способности.)
Очень хороший вопрос.
Необработанный интерфейс реализован в некоторых системах unix (tru64, hpux, solaris)
, но не в Linux.
Необработанный интерфейс ускоряет передачу, потому что Ввод-вывод unix пропускается.
Блочный интерфейс ( / dev / dsk или / dev / disk ) работает медленнее, потому что он использует
unix Система ввода-вывода.
Для ускорения dd (gnu dd can) используйте bs = 30M или bs = 20M в зависимости от вашего аппаратного обеспечения. { {1}} Короткий ответ: НЕТ, это не реализовано, по крайней мере, насколько мне известно. Я использую Linux еще со времен ядра версии 2.2 и никогда не видел rdsk , используемых в unix.