Existe um método de obter uma porcentagem em um DD no Linux?

41

Então aqui está o que está acontecendo.

Iniciei um backup de uma unidade no meu servidor através de um USB ao vivo do Linux. Comecei a copiar a primeira unidade com o ddcomando vanilla; apenas sudo dd if=/dev/sda of=/dev/sdc1então lembrei que isso deixa o console em branco até terminar.

De qualquer maneira, eu precisava executar um backup diferente na mesma unidade, então iniciei esse também sudo dd if=/dev/sdb of=/dev/sdc3 status=progresse recebi uma linha de texto que mostra a taxa atual de transferência e o progresso em bytes.

Eu estava esperando por um método que mostra uma porcentagem do backup em vez de fazer a matemática de quantos bytes são salvos em backup de 1,8 TB. Existe uma maneira mais fácil de fazer isso do que status = progress?

— Hastur
fonte

68

Veja as respostas desta pergunta ^{[ 1 ]}

`pv`

Por exemplo, você pode usar pv antes de começar

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

Saída ^{[ 2 ]} :

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

^{Notas:

Especialmente para arquivos grandes, você pode querer ver man dde definir as opções necessárias para acelerar todo o seu hardware, por exemplo, bs=100Mpara definir o buffer, oflag=syncpara contar os bytes efetivos gravados, talvez direct...

A opção -saceita apenas parâmetros inteiros 1.8T-->1844G.

Como você pode notar nas primeiras linhas, você não precisa de ddtodo.}

`kill -USR1 pid`

Se você já iniciou o ddcomando, depois de individualizar seu PID ( Ctrl- Z+ bge lê-lo, ou pgrep ^dd...), você pode enviar um sinal USR1(ou SIGUSR1, ou SIGINFOveja abaixo) e ler a saída.
Se o PID do programa for 1234 com

kill -USR1 1234

dd responderá no terminal do seu STDERR com algo semelhante ao

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

^{Aviso: No OpenBSD, você pode ter que verificar previamente o comportamento do kill^{[ 3 ]} : use

kill -SIGINFO 1234.

Existe a sigação nomeada SIGINFO. A SIGUSR1um, neste caso, deve encerrar o programa ( dd) ...

uso no Ubuntu -SIGUSR1( 10).}

— Hastur
fonte

9

você certamente encontrará que o uso de 'bs' no comando dd acelera enormemente. Como dd if = / dev / blah of = / tmp / blah bs = 100M para transferir 100 milhões de blocos de cada vez

— Sirex

1

@ Sirex Claro que você precisa definir o bs para otimizar a taxa de transferência em relação ao seu hardware ... Na resposta, basta repetir a linha de comando do OP. :-)

— Hastur 31/01

3

@Criggie: talvez seja porque ddjá havia terminado todas as write()chamadas do sistema e fsyncou closeestava bloqueado aguardando a gravação chegar ao disco. Com um pen drive lento, os limites padrão de buffer de E / S do Linux para o tamanho dos grandes buffers de gravação sujos levam a um comportamento qualitativamente diferente do que os arquivos grandes em discos rápidos, porque os buffers são tão grandes quanto o que você está copiando e ainda leva um tempo perceptível.

— Peter Cordes

5

Ótima resposta. No entanto, quero observar que, no OpenBSD, o sinal certo de morte é SIGINFO, não SIGUSR1. Usar -USR1 no OpenBSD simplesmente matará o dd. Portanto, antes de tentar fazer isso em um novo ambiente, em uma transferência que você não deseja interromper, familiarize-se com o modo como o ambiente age (em um teste mais seguro).

— TOOGAM

1

o conselho sinais para ddé realmente grande informação, especialmente para servidores onde você não pode / não deseja instalarpv

— mike

38

Minha ferramenta principal para esse tipo de coisa é progress:

Essa ferramenta pode ser descrita como um comando C Minúsculo , Sujo, Somente Linux e OSX que procura comandos básicos do coreutils (cp, mv, dd, tar, gzip / gunzip, cat etc.) atualmente em execução no sistema e exibe a porcentagem de dados copiados. Ele também pode mostrar tempo e taxa de transferência estimados e fornece um modo "top-like" (monitoramento).

Ele simplesmente procura /procpor comandos interessantes e, em seguida, procura nos diretórios fde fdinfoencontra os arquivos abertos, procura posições e reporta o status do maior arquivo.

É muito leve e compatível com praticamente qualquer comando.

Acho particularmente útil porque:

comparado ao pvpipe ou dcfldd, não preciso me lembrar de executar um comando diferente ao iniciar a operação, posso monitorar as coisas após o fato;
Em comparação com kill -USR1, ele funciona em praticamente qualquer comando, não preciso sempre verificar a página de manual para ter certeza de que não estou matando acidentalmente a cópia; Além disso, é bom que, quando chamado sem parâmetros, mostre o progresso de qualquer comando "transferência de dados" comum em execução no momento, para que eu nem precise procurar o PID;
comparado a pv -d, novamente, não preciso procurar o PID.

— Matteo Italia
fonte

1

Nota: Você pode monitorar mais do que apenas processos coreutils. Basta especificar o nome do comando com --command <command-name>.

— jpaugh

1

Isso é incrível!

— Floris

25

Execute dd, então, em um shell separado, chame o seguinte comando:

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

Isso fará com que o pv obtenha estatísticas sobre todos os descritores de arquivos abertos do ddprocesso. Ele mostrará a você onde estão os buffer de leitura e gravação.

— sleblanc
fonte

2

Funciona após o fato !? Surpreendente!!

— jpaugh

3

Isso é muito legal. Evita a sobrecarga de largura de banda de memória + comutação de contexto de realmente canalizar todos os dados através de 3 processos! @ jpaugh: Eu acho que apenas olha /proc/$PID/fdinfopara as posições dos arquivos e /proc/$PID/fdpara ver quais arquivos (e, portanto, os tamanhos). Então, sim, é uma idéia muito legal e boa para um recurso, mas eu não chamaria de "incrível", porque existem APIs do Linux que permitem pesquisar as posições dos arquivos de outro processo.

— Peter Cordes

@ PeterCordes Eu não sabia que a posição do arquivo foi exposta pelo kernel. (Passei minha vida preparando cuidadosamente os pvoleodutos com antecedência.) Obviamente, presumi isso quando vi que isso funciona.

— jpaugh

9

Há uma alternativa para dd: dcfldd.

O dcfldd é uma versão aprimorada do GNU dd com recursos úteis para forense e segurança.

Saída de status - o dcfldd pode atualizar o usuário sobre seu progresso em termos da quantidade de dados transferidos e quanto tempo a operação levará.

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

— Antonin Décimo
fonte

É um nome de comando mais longo ... claramente, é inferior. (+1)

— jpaugh 01/02

6

Como porcentagem, você teria que fazer algumas contas, mas é possível obter o progresso de um dd na forma legível por humanos, mesmo depois de já começar, fazendo kill -USR1 $(pidof dd)

O processo dd atual será exibido semelhante a:

11117279 bytes (11 MB, 11 MiB) copiados, 13.715 s, 811 kB / s

— Sirex
fonte

4

Isso é basicamente a mesma coisa que status=progressdá

— rakslice

1

Na verdade, eu estava prestes a dizer que é exatamente a mesma coisa que status = progresso dá.