Puoi usare la "sostituzione del processo" di bash insieme al comando tee per fare questo:
cat drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) | dd of=/dev/sdd
o per chiarezza (a scapito di un po 'di efficienza) puoi fare in modo che l'ultimo ddsia chiamato allo stesso modo degli altri e inviare lo stdout di 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
e se lo hai installato puoi usare il visualizzatore di pipe invece di catottenere un utile indicatore di avanzamento:
pv drive.image | tee >(dd of=/dev/sda) >(dd of=/dev/sdb) >(dd of=/dev/sdc) | dd of=/dev/sdd
Questo legge l'immagine sorgente una sola volta, quindi l'unità sorgente subisce un colpo alla testa, che probabilmente sarà il motivo per cui vedrai un rallentamento esponenziale quando provi a copiare l'immagine più volte con altri metodi. Usando teecome sopra, i processi dovrebbero essere eseguiti alla velocità dell'unità di destinazione più lenta.
Se le unità di destinazione sono collegate tramite USB, tenere presente che potrebbero condividere tutte la larghezza di banda del bus, quindi scrivere molte in parallelo potrebbe non essere più veloce della loro scrittura sequenziale perché il bus USB diventa il collo di bottiglia non l'unità di origine o di destinazione.
Quanto sopra presuppone che tu stia utilizzando Linux o simili (dovrebbe funzionare anche su OSX anche se i nomi dei dispositivi potrebbero essere diversi), se stai utilizzando Windows o qualcos'altro, allora hai bisogno di una soluzione diversa.
modificare
L'imaging sulla rete presenta un problema simile all'imaging di molte unità tramite USB - il canale di trasporto diventa il collo di bottiglia anziché le unità - a meno che il software utilizzato non supporti una qualche forma di trasmissione o trasmissione multicast.
Per il ddmetodo che potresti probabilmente fare daisy chain netcat+ tee+ ddprocessi su ogni macchina in questo modo:
- Computer di origine
cat/ pv/ dds i dati attraverso ncal computer di destinazione 1.
- La macchina di destinazione 1 ha in
ncascolto i dati dalla macchina di origine e li ha convogliati attraverso i teequali a loro volta li invia a dd(e quindi al disco) e un altro ncprocesso che invia alla macchina di destinazione 2.
- La macchina di destinazione 2 ha in
ncascolto i dati dalla macchina di destinazione 1 e li ha convogliati attraverso i teequali a loro volta li invia a dd(e quindi al disco) e un altro ncprocesso che invia alla macchina di destinazione 3.
- e così via fino all'ultima macchina che ha appena
ncraccolto i dati dalla macchina precedente e li ha inviati al disco tramite dd.
In questo modo si utilizza potenzialmente tutta la larghezza di banda della rete, supponendo che lo switch e le schede di rete abbiano negoziato un collegamento full duplex. Invece della macchina di origine che invia 10 copie dei dati (presupponendo 10 macchine di destinazione), quindi ciascuna è limitata a 1/10 della larghezza di banda in uscita che sta inviando solo 1. Ogni macchina di destinazione sta prendendo una copia dei dati e li invia ancora. Potrebbe essere necessario modificare le impostazioni della dimensione del buffer di pv, nce ddper avvicinarsi al meglio le prestazioni pratico.
Se riesci a trovare un software che supporta solo il multicast, sarebbe molto più semplice (e probabilmente un po 'più veloce)! Ma quanto sopra è il tipo di soluzione confusa che potrei essere abbastanza sciocca da provare ...
Modifica ancora
Un altro pensiero. Se l'immagine dell'unità si comprime bene (cosa che farà se grossi pezzi sono pieni di zeri) la larghezza di banda in uscita della macchina di origine non deve essere un problema anche se si invia a molte destinazioni contemporaneamente. Basta comprimere prima l'immagine, trasmetterla ovunque usando tee+ nce decomprimere sulle destinazioni (rete-> nc-> decomprimere-> dd-> disco).