Puede usar la "sustitución de proceso" de bash junto con el comando tee para hacer esto:
cat drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) | dd of=/dev/sdd
o para mayor claridad (a expensas de un poco de eficiencia), puede hacer que el último ddse llame de la misma manera que los demás y enviar el stdout de tee a / dev / null:
cat drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) >(dd of=/dev/sdd) | /dev/null
y si lo tiene instalado, puede usar el visor de tuberías en lugar de catobtener un indicador de progreso útil:
pv drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) | dd of=/dev/sdd
Esto lee la imagen de origen solo una vez, por lo que la unidad de origen sufre golpes de cabeza, lo que probablemente sea la razón por la que ve una desaceleración exponencial cuando intenta copiar la imagen varias veces por otros métodos. Usando teecomo arriba, los procesos deben ejecutarse a la velocidad de la unidad de destino más lenta.
Si tiene las unidades de destino conectadas a través de USB, tenga en cuenta que todas pueden compartir el ancho de banda del bus, por lo que escribir muchas en paralelo puede no ser más rápido que escribirlas secuencialmente porque el bus USB se convierte en el cuello de botella, no en las unidades de origen o de destino.
Lo anterior supone que está utilizando Linux o similar (también debería funcionar en OSX, aunque los nombres de los dispositivos pueden ser diferentes), si está utilizando Windows u otra cosa, entonces necesita una solución diferente.
Editar
La creación de imágenes a través de la red tiene un problema similar a la creación de imágenes de muchas unidades a través de USB: el canal de transporte se convierte en el cuello de botella en lugar de las unidades, a menos que el software que utilice sea compatible con algún tipo de transmisión de transmisión o multidifusión.
Para el ddmétodo, probablemente podría encadenar procesos netcat+ tee+ dden cada máquina de la siguiente manera:
- Máquina de origen
cat/ pv/ dds los datos a través ncde la máquina de destino 1.
- La máquina de destino 1
ncescucha los datos de la máquina de origen y los canaliza a través de los teecuales, a su vez, los envía dd(y, por lo tanto, al disco) y otro ncproceso que envía a la máquina de destino 2.
- La máquina de destino 2
ncescucha los datos de la máquina de destino 1 y los conecta a través de los teecuales, a su vez, los envía dd(y, por lo tanto, al disco) y otro ncproceso que envía a la máquina de destino 3.
- y así sucesivamente hasta la última máquina que acaba de
ncrecoger los datos de la máquina anterior y enviarlos al disco a través de dd.
De esta manera, potencialmente está utilizando su ancho de banda de red completo, suponiendo que su conmutador y las tarjetas de red hayan negociado un enlace dúplex completo. En lugar de que la máquina de origen envíe 10 copias de los datos (suponiendo que 10 máquinas de destino) estén limitadas a 1/10 del ancho de banda saliente, solo está enviando 1. Cada máquina de destino toma una copia de los datos y la envía. de nuevo. Es posible que tenga que ajustar la configuración de tamaño de búfer de pv, ncy ddpara acercarse a un mejor rendimiento práctico.
Sin embargo, si puede encontrar algún software que solo sea compatible con multidifusión, ¡eso sería mucho más fácil (y probablemente un poco más rápido)! Pero lo anterior es el tipo de solución hacky que podría ser tan tonto como para intentar ...
Editar de nuevo
Otro pensamiento Si la imagen de la unidad se comprime bien (lo que ocurrirá si grandes partes de ella están llenas de ceros), el ancho de banda saliente de la máquina de origen no necesita ser un problema, incluso si se envía a muchos destinos a la vez. Simplemente comprima la imagen primero, transmítala a todas partes usando tee+ ncy descomprima en los destinos (red-> nc-> descompresor-> dd-> disco).