Come massimizzare la velocità della clonazione del disco tramite `dd`?

Voglio copiare l' intero disco da / dev / sda a / dev / sdb in modo accurato, quindi vorrei usare il ddcomando in Linux, ma ci sono due opzioni che mi confondono bse sync.

dd if = / dev / sda di = / dev / sdb bs = 4096 conv = notrunc, noerror, sync

• Devo aggiungere syncun'opzione come suggerito da wiki.archlinux.org ?

• Devo impostare bs=16384kBla dimensione della cache del disco anziché il numero maggiore per massimizzare la velocità?

Devo aggiungere l'opzione di sincronizzazione come suggerito wiki.archlinux.org?

Se hai intenzione di utilizzare l' conv=noerroropzione, ti conv=syncconviene utilizzarla o potresti finire con un backup inutile.

Per la pagina man di Linux

Each CONV symbol may be: 
...
sync
    pad every input block with NULs to ibs-size; when used with block or unblock, pad with spaces rather than NULs 

Questa opzione che può aggiungere il riempimento è necessaria quando si specifica anche l' noerroropzione "continua dopo errori di lettura". Il controller del disco non fornisce dati settoriali per il buffer di input quando si verifica un errore di lettura (ovvero irreversibile). Se dd è terminato per un tale errore (come farebbe normalmente), la mancanza di dati non è un problema.

Tuttavia, quando viene specificato "Continua dopo errori di lettura", la mancanza di dati è quindi un problema. Se il buffer di input non è riempito per tenere conto dei settori che sono / sono illeggibili, i dati successivi che vengono scritti saranno compensati dai settori appropriati in cui dovrebbero essere scritti. O se i dati successivi saltati i settori di destinazione corrispondenti agli errori (o hanno fatto un cercano (in dd gergo) al suo settore corrispondente), quindi i dati della spazzatura a quelli saltati-over settori sarebbero trattati come copie dei dati originali.

Se si utilizza dd per copiare blocchi con un numero di sequenza integrale, il padding potrebbe non essere necessario per rilevare o tenere conto dei blocchi mancanti. Non si può presumere che i settori di dischi grezzi abbiano una tale numerazione di sequenza integrale e richiedono il riempimento per cercare di preservare l'integrità del file system copiato.

Nota che ci sono due syncopzioni disponibili con dd .
Uno è conv=synce l'altro è iflag=sync. Hanno significati diversi.

Dovrei impostare bs = 16384kB come dimensione della cache del disco piuttosto che il numero maggiore per massimizzare la velocità?

A quale "il numero più grande" ti riferisci?

Il bsparametro, size block, non ha nulla a che fare con la dimensione della cache (anche se non sono sicuro di quale cache si riferisca.)
16 MB è probabilmente eccessivo, in quanto potrebbe non esserci nemmeno quanta memoria DMAable disponibile per bloccare . Esistono alcuni test di benchmark per variare la dimensione del blocco e quelli che ho visto, come questo , confermano il mio sospetto che ci sia una dimensione di rendimento decrescente (o almeno non più), che sembra essere di circa 512 KB.

Un valore classico per bsquando si copiava un HDD era la dimensione della traccia in byte (o num_of_sectors_per_track * 512 byte). Ma dal momento che i moderni HDD usano la registrazione bit suddivisa in zone e variano la densità areale, non esiste un "numero di settori per traccia" fisso (o noto per quella materia). La specifica tipica pubblicata di "63 settori per traccia" su unità moderne è semplicemente una comodità numerica.

Non che dd non svolgerà l'attività, ma potresti prendere in considerazione l'utilizzo di dd_rescue se è disponibile. Fornisce la capacità di gestire meglio tutti i settori danneggiati e svolge un lavoro migliore nel fornire informazioni sullo stato durante la copia. La sintassi è leggermente diversa:

# dd_rescue [options] infile outfile
# using a 1M block size allows dd_rescue to adjust it's reads/writes to the limits of the OS buffer 

dd_rescue -b 1M /dev/sda /dev/sdb

#sample of the status
dd_rescue: (info): Using softbs=1048576, hardbs=4096
dd_rescue: (info): ipos:   1048576000.0k, opos:   1048576000.0k, xferd:   1048576000.0k
               errs:      0, errxfer:         0.0k, succxfer:   1048576.0k
         +curr.rate:  107936kB/s, avg.rate:  107268kB/s, avg.load: 98.6%
         >-----------------------------------------< 100%  ETA:  0:00:00

Potresti scoprire che aumentare leggermente la velocità del clone è meno importante che essere informato su quanto tempo impiega il processo.

Tieni presente che le velocità di trasferimento medie iniziali possono essere fuorvianti, in quanto i primi 50 GB circa di un'unità disco rotante sono fino al 30% più veloci rispetto al resto. Copia dalle tracce fisicamente più corte all'interno del disco e rallenta man mano che le tracce si allungano. Ovviamente non lo vedrai per gli SSD.

bssignifica che n b(byte) vengono letti e scritti ogni volta. Sta per dimensione del blocco . bsnon influisce necessariamente sulla dimensione del blocco di input ibs né sulla dimensione del blocco di output obs .

syncindica al processo di attendere che tutti i dati siano stati scritti correttamente sul disco prima di passare al blocco successivo . Di solito è meglio garantire l'integrità dei dati ed evitare la perdita di dati in caso di interruzione dell'alimentazione (come scollegare l'unità nel momento in cui ha finito di scrivere i dati), ma è più lenta .

Senza syncil processo di copia è complessivamente più veloce e il dispositivo può essere scritto prima che con syncabilitato, ma potresti notare che quando le informazioni sono state copiate completamente, in effetti il ​​disco potrebbe ancora scrivere informazioni dalla sua cache al supporto reale. Questo è spesso utile per i dischi rigidi o quando non si prevede di scollegare il dispositivo non appena la copia è stata eseguita.

In poche parole:

• sync → attendere che le informazioni siano completamente scritte per un vero supporto.
• senza sync→ inviare informazioni. al dispositivo e lasciarlo gestire la scrittura reale.

È possibile accelerare (un po ') il processo con l' syncopzione abilitata utilizzando blocchi di grandi dimensionibs per evitare l'accesso ripetuto al disco in tempi brevi e rallentando così l'intero processo.

Ho sempre usato ddsenza l' syncopzione e non ho mai avuto problemi, attendi solo che le informazioni siano completamente scritte prima di espellere qualsiasi dispositivo.