Estou em um busybox 1.27sistema somente Linux, portanto não output=progressestá disponível, nenhuma implementação do próprio busybox pvé pipe_progressnem pvele mesmo.
Eu tenho duas perguntas. O primeiro é baseadohttps://www.linux.com/training-tutorials/show-progress-when-using-dd/. Diz que ao enviar o USR1sinal para ddele “pausa” o processo e ddapós a impressão seu status atual continuará com o trabalho que estava fazendo. Estou tentando fazer alguns testes de benchmark, ddentão gostaria de ter um impacto mínimo na ddoperação. Quero obter uma saída da operação atual a cada segundo porque os dados que estão passando ddestão flutuando e é importante para mim reconhecer quando a taxa de transferência cai.
Primeira pergunta: É verdade que 'dd' "pausa" toda vez que recebe um USR1sinal?
Se ddpausar a cada segundo, adicionarei horas à operação quando dezenas de gigabytes estiverem sendo transferidos.
Segunda questão: Supondosimcomo resposta à primeira pergunta, gostaria de saber se é possível imprimir ddseu status atual sem enviar nenhum sinal ao processo, talvez algum tipo de redirecionamento para STDOUT(como 2>&1)?
O que estou me referindo é:
# bs with 1Mib so I can have more control on the test.
dd if=/dev/zero of=/dev/null bs=1048576 count=1024
# Printing current operation status.
sudo kill -USR1 $dd_pid
Responder1
dd if=/dev/zero of=/dev/null bs=1048576 count=1024
Observe queddpode manipular dados, pelo menosao usar o bsparâmetro. Esua vantagem de desempenhoé pequeno, na melhor das hipóteses, se você escolher a dedo um tamanho de bloco ideal para a configuração específica do seu sistema: catou cppode fazer melhor e, no máximo, é apenas um pouco mais lento. Portanto, não use ddse não for necessário.
Observe que desde a versão 1.23, o BusyBox usa osendfilechamada de sistema para copiar dados, em vez de usar reade write. Somente cópias simples como cate cpusam sendfile, entretanto: ddsão forçados a usar read/ writeporque desejam controle preciso sobre os tamanhos. Portanto, com BusyBox ≥1,23 cate cpé muito provável que seja mais rápido que dd.
É verdade que 'dd' "pausa" toda vez que recebe um sinal USR1?
Tecnicamente sim, é preciso “pausar” para controlar o sinal. No entanto, a pausa consiste apenas em algumas instruções da CPU (a parte mais cara, de longe, é imprimir a saída do progresso). Portanto, isso não invalida seu benchmark de forma alguma.
Se dd pausar a cada segundo, adicionarei horas à operação quando dezenas de gigabytes estiverem sendo transferidos.
Não, você errou suas ordens de magnitude. Você adicionará talvez 0,1% do tempo em um thread de CPU única. O principal custo é o tempo de kernel para o programa de benchmarking, e não dd, portanto, é intrínseco ao que você deseja fazer, não à maneira como você o implementa.
se for possível fazer com que o dd imprima seu status atual sem enviar nenhum sinal ao processo
Bem não. Já existe uma maneira simples, historicamente estabelecida, padrão e fácil de fazer isso. Por que haveria outra maneira que seria mais difícil de implementar?
No Linux, existe uma maneira genérica de saber a que ponto uma cópia chegou. Não depende de qual programa está fazendo a cópia, embora nem sempre funcione com arquivos especiais. Descubra o ID do processo $pidque está fazendo a cópia e quais descritores de arquivo ele está usando para entrada e saída. ddlê do fd 0 e grava no fd 1. O BusyBox cpnormalmente lê do fd 3 e grava no fd 4. Você pode verificar qual arquivo está aberto em qual descritor de arquivo por meio dos links simbólicos em /proc/$pid/fd.
$ cp /dev/zero /dev/null & pid=$!
$ readlink /proc/$pid/fd/3
/dev/zero
$ readlink /proc/$pid/fd/4
/dev/null
E você pode verificar a posição no descritor de arquivo $n$em /proc/$pid/fd/$n.
$ cat /proc/$pid/fdinfo/4
pos: 74252288
flags: 0100001
mnt_id: 27
No entanto, observe que a posição do descritor de arquivo pode não ser atualizada com arquivos especiais como /dev/zero, /dev/null, pipes ou soquetes. É sempre atualizado com arquivos regulares. Não sei se está atualizado para dispositivos de bloco. Portanto, provavelmente não fornecerá nenhuma informação para copiar entre /dev/zeroe /dev/null, mas pode funcionar no seu caso de uso real.
Responder2
Você também pode consultar o progresso por meio da /procinterface.
# dd bs=1M if=/dev/mmcblk0 of=/dev/null &
# pidof dd
1358
Portanto, as informações sobre esse processo podem ser encontradas em /proc/1358:
# ls -l /proc/1358/fd
total 0
lr-x------ 1 root root 64 Nov 2 09:16 0 -> /dev/mmcblk0
l-wx------ 1 root root 64 Nov 2 09:16 1 -> /dev/null
lrwx------ 1 root root 64 Nov 2 09:16 2 -> /dev/pts/0
Filehandle 0 é o if=/dev/mmcblk0, agora onde está o progresso?
# cat /proc/1358/fdinfo/0
pos: 2132803584
flags: 0400000
mnt_id: 17
# cat /proc/1358/fdinfo/0
pos: 2366636032
flags: 0400000
mnt_id: 17
# cat /proc/1358/fdinfo/0
pos: 2587885568
flags: 0400000
mnt_id: 17
Dessa forma, para o busybox dd, você também pode derivar o progresso de seu valor fdinfo pos.
Dito isto, o envio moderado do sinal USR1 deve ter um impacto mínimo no desempenho. Em um sistema embarcado com poucos recursos, pesquisar o fdinfo pode muito bem ter um impacto semelhante.