Есть ли способ получения процента на DD в Linux?

41

Итак, вот что происходит.

Я запустил резервное копирование диска на моем сервере через Linux live USB. Я начал копировать первый диск с помощью ddкоманды vanilla; просто sudo dd if=/dev/sda of=/dev/sdc1и потом я вспомнил , что это просто оставляет консоли пустой до тех пор, пока не закончится.

В любом случае мне нужно было запустить другое резервное копирование на тот же диск, поэтому я запустил его также с, sudo dd if=/dev/sdb of=/dev/sdc3 status=progressа затем получил строку текста, которая показывает текущую скорость передачи, а также прогресс в байтах.

Я надеялся на метод, который показывает процент резервного копирования, а не подсчитывает, сколько байтов резервируется из 1,8 ТБ. Есть ли более простой способ сделать это, чем статус = прогресс?

Hastur
источник

Ответы:

68

Смотрите ответы на этот вопрос [ 1 ]

pv

Например, вы можете использовать, pv прежде чем начать

sudo apt-get install pv    # if you do not have it
pv < /dev/sda > /dev/sc3   # it is reported to be faster
pv /dev/sda > /dev/sc3     # it seems to have the same speed of the previous one
#or 
sudo dd if=/dev/sda | pv -s 1844G | dd of=/dev/sdc3  # Maybe slower 

Выход [ 2 ] :

440MB 0:00:38 [11.6MB/s] [======>                             ] 21% ETA 0:02:19

Примечания:
Особенно для больших файлов вы можете захотеть увидеть man ddи установить параметры, необходимые для ускорения всего на вашем оборудовании, например, bs=100Mдля установки буфера, oflag=syncдля подсчета эффективных записанных байтов, может быть direct...
Эта опция -sпринимает только целочисленные параметры 1.8T-->1844G.
Как вы можете заметить из первых строк, вам не нужно ddвообще.


kill -USR1 pid

Если вы уже запустили в ddкоманду после того , как вы индивидуировано его PID ( Ctrl- Z+ bgи вы читаете это, или pgrep ^dd...) , вы можете послать сигнал USR1(или SIGUSR1, или SIGINFOсмотри ниже) и читать вывод.
Если PID программы 1234 с

kill -USR1 1234

dd ответит на терминале своего STDERR чем-то похожим на

4+1 records in
4+0 records out
41943040 bytes (42 MB) copied, 2.90588 s, 14.4 MB/s

Предупреждение: в OpenBSD вам, возможно, придется заранее проверить поведение kill[ 3 ] : используйте вместо этого
kill -SIGINFO 1234.
Существует подпись SIGINFO. Тот SIGUSR1, в этом случае, должен завершить программу ( dd) ...
В Ubuntu use -SIGUSR1( 10).

Hastur
источник
9
вы почти наверняка обнаружите, что использование 'bs' в команде dd значительно ускоряет ее. Как dd if = / dev / blah of = / tmp / blah bs = 100M для передачи 100M блоков одновременно
Sirex
1
@Sirex Конечно, вы должны установить bs для оптимизации скорости передачи в зависимости от вашего оборудования ... В ответ просто повторяется командная строка OP. :-)
Хастур
3
@Criggie: возможно, потому, ddчто все write()системные вызовы уже завершены , fsyncили они closeбыли заблокированы в ожидании записи на диск. При медленном USB-накопителе пороговые значения по умолчанию для буфера ввода-вывода в Linux, определяющие, насколько большими могут быть грязные буферы записи, ведут к качественно другому поведению, чем при работе с большими файлами на быстрых дисках, потому что буферы так же велики, как и то, что вы копируете, и по-прежнему занимает заметное время.
Питер Кордес
5
Отличный ответ. Однако я хочу отметить, что в OpenBSD правильным сигналом уничтожения является SIGINFO, а не SIGUSR1. Использование -USR1 в OpenBSD просто убьет dd. Поэтому, прежде чем попробовать это в новой среде, при передаче, которую вы не хотите прерывать, вы можете ознакомиться с тем, как действует среда (в более безопасном тесте).
TOOGAM
1
Совет по сигналам dd- действительно полезная информация, особенно для серверов, где вы не можете / не хотите устанавливатьpv
Майк
38

Мой инструмент для такого рода вещей progress:

Этот инструмент может быть описан как Tiny , Dirty, Linux-and-OSX-Only C команда, которая ищет основные команды coreutils (cp, mv, dd, tar, gzip / gunzip, cat и т. Д.), В настоящее время работающие в вашей системе, и отображает процент скопированных данных. Он также может показывать приблизительное время и пропускную способность и обеспечивает режим «сверху» (мониторинг).

Снимок экрана "<code> progress </ code> in action"

Он просто сканирует /procинтересные команды, а затем смотрит на каталогах , fdи fdinfoнайти открытые файлы и искать позиции, а также отчеты о состоянии самого большого файла.

Он очень легкий и совместим практически с любой командой.

Я нахожу это особенно полезным, потому что:

  • по сравнению с pvin pipe или dcfldd, когда я запускаю операцию, мне не нужно запускать другую команду, я могу отслеживать вещи по факту;
  • по сравнению с тем kill -USR1, что он работает практически с любой командой, мне не нужно всегда перепроверять man-страницу, чтобы убедиться, что я не случайно убил копию; также приятно, что при вызове без параметров он показывает ход выполнения любой распространенной команды «передача данных», выполняемой в данный момент, поэтому мне даже не нужно искать PID;
  • по сравнению с pv -d, опять же, мне не нужно искать PID.
Matteo Italia
источник
1
Примечание. Вы можете отслеживать не только процессы coreutils. Просто укажите название команды с помощью --command <command-name>.
jpaugh
1
Это круто!
Флорис
25

Запустите dd, затем в отдельной оболочке вызовите следующую команду:

pv -d $(pidof dd) # root may be required

Это заставит pv получить статистику по всем открытым файловым дескрипторам ddпроцесса. Он покажет вам, где находится буфер чтения и записи.

sleblanc
источник
2
Работает по факту !? Удивительно!!
jpaugh
3
Это очень круто. Это позволяет избежать издержек на использование полосы пропускания памяти и переключения контекста, когда все данные передаются через 3 процесса! @jpaugh: Я думаю, что он просто смотрит на /proc/$PID/fdinfoпозиции файлов, и на, /proc/$PID/fdчтобы увидеть, какие файлы (и, следовательно, размеры). Так что да, очень крутая и хорошая идея для функции, но я бы не назвал ее «удивительной», потому что есть Linux API, которые позволяют опрашивать позиции файлов другого процесса.
Питер Кордес
@PeterCordes Я не знал, что положение файла было выставлено ядром. (Я тратил всю свою жизнь на тщательную подготовку pvтрубопроводов заранее.) Конечно, я предполагал столько же, как только увидел, что это работает.
jpaugh
9

Там есть альтернатива dd: dcfldd.

dcfldd - это расширенная версия GNU dd с функциями, полезными для криминалистики и безопасности.

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

dcfldd if=/dev/zero of=out bs=2G count=1 # test file
dcfldd if=out of=out2 sizeprobe=if
[80% of 2047Mb] 52736 blocks (1648Mb) written. 00:00:01 remaining.

http://dcfldd.sourceforge.net/
https://linux.die.net/man/1/dcfldd

Антонин Десимо
источник
Это более длинное имя команды ... очевидно, оно уступает. (+1)
jpaugh
6

В процентном соотношении вам придется выполнять некоторые математические операции, но вы можете получить прогресс dd в удобочитаемой для человека форме, даже после того, как уже начали, выполнив kill -USR1 $(pidof dd)

Текущий процесс дд будет отображаться как:

Скопировано 11117279 байт (11 МБ, 11 МБ), 13,715 с, 811 КБ / с

Sirex
источник
4
Это в основном то же самое, что status=progressдает
Ракслице
1
Я на самом деле собирался сказать, что это то же самое, что дает статус = прогресс.