Estoy en un busybox 1.27sistema solo Linux, por lo que no está disponible, no hay output=progressninguna implementación propia de Busybox ni en sí misma.pvpipe_progresspv
Tengo dos preguntas. La primera se basa enhttps://www.linux.com/training-tutorials/show-progress-when-using-dd/. Dice que al enviarle la USR1señal dd"pausa" el proceso y ddluego de imprimir su estado actual continuará con el trabajo que estaba realizando. Estoy intentando hacer algunas pruebas comparativas, ddpor lo que me gustaría tener un impacto mínimo en la ddoperación. Quiero obtener un resultado de la operación actual cada segundo porque los datos que pasan ddfluctúan y es importante para mí reconocer cuándo cae la tasa de transferencia.
Primera pregunta: ¿Es cierto que 'dd' "hace una pausa" cada vez que recibe una USR1señal?
Si ddhace una pausa cada segundo, agregaré horas a la operación cuando se transfieran decenas de gigabytes.
Segunda pregunta: AsumiendoSíComo respuesta a la primera pregunta, me gustaría saber si es posible imprimir ddsu estado actual sin enviar ninguna señal al proceso, tal vez algún tipo de redirección STDOUT(como 2>&1).
A lo que me refiero es:
# 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
Respuesta1
dd if=/dev/zero of=/dev/null bs=1048576 count=1024
Tenga en cuenta queddpuede alterar los datos, al menosal usar el bsparámetro. Ysu ventaja de rendimientoes, en el mejor de los casos, pequeño si selecciona manualmente un tamaño de bloque óptimo para la configuración particular de su sistema: cato cppuede hacerlo mejor, y como máximo es solo un poco más lento. Así que no lo uses ddsi no es necesario.
Tenga en cuenta que desde la versión 1.23, BusyBox utiliza elsendfilellamada al sistema para copiar datos, en lugar de usar ready write. Sólo se utilizan copias simples como caty , sin embargo: se ve obligado a utilizar / porque quiere un control preciso sobre los tamaños. Entonces, con BusyBox ≥1.23, es muy probable que sea más rápido que .cpsendfileddreadwritecatcpdd
¿Es cierto que 'dd' "hace una pausa" cada vez que recibe una señal USR1?
Técnicamente sí, tiene que “pausarse” para manejar la señal. Sin embargo, la pausa es solo unas pocas instrucciones de la CPU (la parte más costosa, con diferencia, es imprimir el resultado del progreso). Entonces esto no invalida su punto de referencia de ninguna manera.
Si dd se detiene cada segundo, agregaré horas a la operación cuando se transfieran decenas de gigabytes.
No, tienes mal tus órdenes de magnitud. Agregará tal vez el 0,1% del tiempo en un subproceso de una sola CPU. El costo principal es el tiempo del kernel para el programa de evaluación comparativa, no el costo dd, por lo que es intrínseco a lo que desea hacer, no a la forma en que lo implementa.
si es posible hacer que dd imprima su estado actual sin enviar ninguna señal al proceso
Bueno no. Ya existe una forma sencilla, históricamente establecida, estándar y fácil de hacerlo. ¿Por qué habría otra forma que sería más difícil de implementar?
En Linux, existe una forma genérica de saber el punto al que ha llegado una copia. No depende de qué programa esté haciendo la copia, aunque no siempre funciona con archivos especiales. Descubra el ID del proceso $pidque realiza la copia y qué descriptores de archivo utiliza para entrada y salida. ddlee desde fd 0 y escribe en fd 1. BusyBox cpnormalmente lee desde fd 3 y escribe en fd 4. Puede verificar qué archivo está abierto en qué descriptor de archivo a través de los enlaces simbólicos en /proc/$pid/fd.
$ cp /dev/zero /dev/null & pid=$!
$ readlink /proc/$pid/fd/3
/dev/zero
$ readlink /proc/$pid/fd/4
/dev/null
Y puede verificar la posición en el descriptor del archivo $n$en formato /proc/$pid/fd/$n.
$ cat /proc/$pid/fdinfo/4
pos: 74252288
flags: 0100001
mnt_id: 27
Sin embargo, tenga en cuenta que es posible que la posición del descriptor de archivo no se actualice con archivos especiales como /dev/zero,, /dev/nulltuberías o enchufes. Siempre se actualiza con archivos regulares. No sé si está actualizado para dispositivos en bloque. Por lo tanto, es probable que no le brinde ninguna información para copiar entre /dev/zeroy /dev/null, pero podría funcionar en su caso de uso real.
Respuesta2
También puede consultar el progreso a través de la /procinterfaz.
# dd bs=1M if=/dev/mmcblk0 of=/dev/null &
# pidof dd
1358
Entonces la información sobre este proceso se encuentra en /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 es el if=/dev/mmcblk0, ahora ¿dónde está el progreso?
# 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
De esta manera, para Busybox dd, también puede derivar el progreso de su valor fdinfo pos.
Dicho esto, enviar la señal USR1 con moderación debería tener un impacto mínimo en el rendimiento. En un sistema integrado con pocos recursos, sondear fdinfo también podría tener un impacto similar.