Esiste un metodo per ottenere una percentuale su un DD in Linux?


41

Quindi ecco cosa sta succedendo.

Ho avviato un backup di un'unità sul mio server tramite una USB live Linux. Ho iniziato a copiare la prima unità con il ddcomando vanilla; solo sudo dd if=/dev/sda of=/dev/sdc1e poi mi sono ricordato che questo lascia vuota la console fino al termine.

Avevo comunque bisogno di eseguire un backup diverso sulla stessa unità, quindi ho iniziato anche quello con sudo dd if=/dev/sdb of=/dev/sdc3 status=progresse poi ho ricevuto una riga di testo che mostra l'attuale velocità di trasferimento e lo stato di avanzamento dei byte.

Speravo in un metodo che mostra una percentuale del backup invece di fare i calcoli su quanti byte sono stati sottoposti a backup da 1,8 TB. C'è un modo più semplice per farlo che status = progress?

Risposte:


68

Vedi le risposte a questa domanda [ 1 ]

pv

Ad esempio puoi usare pv prima di iniziare

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 

Uscita [ 2 ] :

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

Note:
Soprattutto per file di grandi dimensioni potresti voler vedere man dde impostare le opzioni necessarie per velocizzare tutto sul tuo hardware, ad esempio bs=100Mper impostare il buffer, oflag=syncper contare i byte effettivi scritti, forse direct...
L'opzione -saccetta solo parametri interi 1.8T-->1844G.
Come puoi notare dalle prime righe, non ti serve ddaffatto.


kill -USR1 pid

Se hai già lanciato il ddcomando, dopo aver individuato il suo PID ( Ctrl- Z+ bge averlo letto, o pgrep ^dd...) puoi inviare un segnale USR1(o SIGUSR1, o SIGINFOvedere sotto) e leggere l'output.
Se il PID del programma è 1234 con

kill -USR1 1234

dd risponderà sul terminale del suo STDERR con qualcosa di simile a

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

Avvertenza: Sotto OpenBSD potresti dover controllare in anticipo il comportamento di kill[ 3 ] : usa invece
kill -SIGINFO 1234.
Esiste la sigazione denominata SIGINFO. L' SIGUSR1uno, in questo caso, dovrebbe terminare il programma ( dd) ...
uso sotto Ubuntu -SIGUSR1( 10).


9
quasi sicuramente scoprirai che usare 'bs' sul comando dd lo accelera enormemente. Come dd if = / dev / blah of = / tmp / blah bs = 100M per trasferire 100M blocchi alla volta
Sirex

1
@Sirex Ovviamente devi impostare bs per ottimizzare la velocità di trasferimento in relazione al tuo hardware ... Nella risposta è appena ripetuta la linea di comando dell'OP. :-)
Hastur

3
@Criggie: questo è forse perché ddaveva già finito tutte le write()chiamate di sistema, e fsynco closeè stato bloccato in attesa che le scritture su disco portata. Con una chiavetta USB lenta, le soglie del buffer I / O Linux predefinite per quanto possono essere grandi i buffer di scrittura sporchi portano a comportamenti qualitativamente diversi rispetto ai file di grandi dimensioni su dischi veloci, perché i buffer sono grandi quanto quello che stai copiando e richiede ancora tempo notevole.
Peter Cordes,

5
Bella risposta. Tuttavia, voglio notare che in OpenBSD il giusto segnale di kill è SIGINFO, non SIGUSR1. L'uso di -USR1 in OpenBSD ucciderà semplicemente dd. Quindi, prima di provare questo in un nuovo ambiente, su un trasferimento che non vuoi interrompere, potresti voler familiarizzare con il comportamento dell'ambiente (su un test più sicuro).
TOOGAM

1
i consigli sui segnali ddsono davvero ottime informazioni, specialmente per i server in cui non è possibile / non si desidera installarepv
mike

38

Il mio strumento di riferimento per questo tipo di cose è progress:

Questo strumento può essere descritto come un comando Tiny , Dirty, solo Linux e OSX-Solo C che cerca i comandi di base coreutils (cp, mv, dd, tar, gzip / gunzip, cat, ecc.) Attualmente in esecuzione sul sistema e visualizza la percentuale di dati copiati. Può anche mostrare il tempo e il throughput stimati e fornisce una modalità "top-like" (monitoraggio).

Schermata "<code> progress </code> in action"

Cerca semplicemente /proci comandi interessanti, quindi cerca le directory fde fdinfotrova i file aperti e cerca le posizioni, e riporta lo stato del file più grande.

È molto leggero e compatibile praticamente con qualsiasi comando.

Lo trovo particolarmente utile perché:

  • rispetto a pvin pipe o dcfldd, non devo ricordare di eseguire un comando diverso quando avvio l'operazione, posso monitorare le cose dopo il fatto;
  • rispetto a kill -USR1, funziona praticamente su qualsiasi comando, non devo sempre ricontrollare la manpage per assicurarmi di non uccidere accidentalmente la copia; inoltre, è bello che, se invocato senza parametri, mostri l'avanzamento di qualsiasi comando comune di "trasferimento dati" attualmente in esecuzione, quindi non devo nemmeno cercare il PID;
  • rispetto a pv -d, ancora una volta non ho bisogno di cercare il PID.

1
Nota: è possibile monitorare più di semplici processi coreutils. Basta specificare il nome del comando con --command <command-name>.
jpaugh

1
Questo e spettacolare!
Floris,

25

Esegui dd, quindi, in una shell separata, invoca il seguente comando:

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

Ciò consentirà a pv di ottenere statistiche su tutti i descrittori di file aperti del ddprocesso. Ti mostrerà entrambi dove si trovano il buffer di lettura e scrittura.


2
Funziona dopo il fatto !? Stupefacente!!
jpaugh

3
È molto bello. Evita l'overhead della larghezza di banda di memoria + dell'interruttore di contesto di inoltrare effettivamente tutti i dati attraverso 3 processi! @jpaugh: immagino che cerchi solo /proc/$PID/fdinfole posizioni dei file e /proc/$PID/fdper vedere quali file (e quindi le dimensioni). Quindi sì, molto interessante e una buona idea per una funzionalità, ma non la definirei "straordinaria" perché ci sono API di Linux che consentono di sondare le posizioni dei file di un altro processo.
Peter Cordes,

@PeterCordes Non mi ero reso conto che la posizione del file fosse esposta dal kernel. (Ho trascorso la mia vita a preparare pvin anticipo le condotte in modo accurato .) Naturalmente, una volta ho visto che ho visto che funziona.
jpaugh

9

C'è un'alternativa a dd: dcfldd.

dcfldd è una versione avanzata di GNU dd con funzionalità utili per la medicina legale e la sicurezza.

Output di stato - dcfldd può aggiornare l'utente dei suoi progressi in termini di quantità di dati trasferiti e di quanto tempo impiegherà più tempo.

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


È un nome di comando più lungo ... chiaramente, è inferiore. (+1)
jpaugh

6

In percentuale dovresti fare alcuni calcoli, ma puoi ottenere i progressi di un dd in forma leggibile dall'uomo, anche dopo aver già iniziato, facendo kill -USR1 $(pidof dd)

L'attuale processo dd verrà visualizzato in modo simile a:

11117279 byte (11 MB, 11 MiB) copiato, 13.715 s, 811 kB / s


4
Questa è sostanzialmente la stessa cosa che status=progress
rakslice il

1
Stavo per dire che è esattamente la stessa cosa che lo status = progresso dà.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.