Почему dd читает из устройства вывода?
Я пытался установить несколько пакетов Ubuntu на Debian Wheezy
Вот в чём проблема: Ubuntu и Debian используют один и тот же формат пакетов, но вы не можете так просто смешать пакеты Debian и Ubuntu в одной и той же системе, потому что выпуски имеют разные версии пакетов. Вы получите аналогичные проблемы, если смешаете несколько выпусков Debian или Ubuntu. Иногда это можно сделать, в основном, если вы устанавливаете пакеты с листьями (пакеты, от которых не зависит ни один другой пакет), но это не рекомендуется.
$ md5 /usr/sbin/mDNSResponder
MD5 (/usr/sbin/mDNSResponder) = 205d44c2b62b8b8c2cef5b84e6da7c79
Точнее говоря, проблема заключается в том, что у вас установлены разные версии пакета [112954]libqtwebkit4[112955] для разных архитектур ([112956]i386[112957] и [112958]amd64[112959]). Вам нужна одна и та же версия для обеих архитектур. [112960]apt-get install libqtwebkit4 libqtwebkit4:i386[112961] может это исправить, хотя возможно, что вы достигли состояния, в котором требуется ручное управление. В принципе, если вы достигли этого состояния только с APT, то APT должен быть способен вытащить вас из него. С другой стороны, если вы вызвали [112962]dpkg[112963] вручную, то ожидается, что может потребоваться какое-то ручное исправление.[112353].
Я столкнулся с аналогичной ситуацией при безопасной очистке внешнего жесткого диска (USB 2.0): длительные периоды чтения, за которыми следуют несколько секунд записи с высокой пропускной способностью, когда я ожидал 100% записи. Я использовал pv, чтобы показать мне общую скорость записи (см. Команду ниже), и я получал в среднем 10 МБ / с, пакетами по 14 МБ / с в течение ~ 10 секунд, а затем несколько кБ / с. Мой вывод iostat очень похож на ваш.
Оказалось, что проблема заключалась в моем слишком маленьком размере блока dd (512 байт). Я подозреваю, что происходит то, что ядро считывает блоки в свои буферы размером 1 КБ на блок, так что dd может перезаписывать 512 байт за раз, которые затем сбрасываются. Я не эксперт по ядру, так что это просто предположение.
Я могу сказать, что увеличение размера моего dd-блока до 72 КБ имело огромное значение . Сейчас я вижу> 40 МБ / с. Это довольно близко к теоретическому максимуму, который может обеспечить USB 2.0 (480 Кб / с, не считая накладных расходов USB), а также довольно близко к максимальной устойчивой скорости записи, которую может достичь этот 10-летний диск (что-то вроде 55 МБ / с), поэтому Доволен, что это более-менее голая скорость.
Вот команда, которую я использую для очистки диска:
openssl enc -aes-256-ctr -pass \
pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
-nosalt </dev/zero \
| pv -bartpes 160041885696 -B 128K \
| dd bs=72K count=2170707 of=/dev/sdf iflag=fullblock
Строки 1-3 передают / dev / zero через шифрование AES-256-CTR с использованием пароля, сгенерированного из / dev / urandom. Итак, это поток криптографически случайного мусора.
Строка 4 показывает прогресс, учитывая количество байтов на диске 160 ГБ и размер буфера передачи в pv 128 КБ.
Строка 5 использует размер блока, который я выбрал с помощью калькулятора, пытаясь найти наибольшее кратное 512, которое было множителем общего # байтов диска. iflag = fullblock заставляет dd многократно читать в свой буфер, пока перед записью не будет 1 полный блок.