Perché specificare la dimensione del blocco quando si copiano dispositivi di dimensioni finite?


14

Nelle esercitazioni online si suggerisce spesso di usare il comando seguente per copiare un CD-ROM in un'immagine ISO:

$ dd if=/dev/dvd of=foobar.iso bs=2048

Perché è necessario specificare la dimensione in byte? Ho notato che in effetti il ​​2048 è la dimensione in byte standard per le immagini CDROM, ma sembra che ddsenza specificare bs=o anche count=funzionare.

In quali circostanze sarebbe problematico non specificare bs=o count=quando si copia da un dispositivo di dimensioni finite?

Risposte:


12

Quando è adatto per copiare i dati? (o, quando sono read () e write () partial) indica un avvertimento importante quando si usa count: ddpuò copiare blocchi parziali, quindi quando viene dato countsi fermerà dopo il dato numero di blocchi, anche se alcuni dei blocchi erano incompleti. Pertanto bs * count, è possibile che vengano copiati meno di byte, a meno che non venga specificato iflag=fullblock.

La dimensione del blocco predefinita per dd è 512 byte. countè un limite; come suggerisce la tua domanda, non è necessario quando si copia un dispositivo di dimensioni finite, ed è realmente destinato a copiare solo una parte di un dispositivo.

Penso che ci siano due aspetti da considerare qui: prestazioni e recupero dei dati.

Per quanto riguarda le prestazioni, idealmente si desidera che la dimensione del blocco sia almeno uguale e un multiplo della dimensione del blocco fisico sottostante (quindi 2048 byte durante la lettura di un CD-ROM). Al giorno d'oggi, infatti, puoi anche specificare blocchi di dimensioni maggiori per dare ai sistemi di cache di base la possibilità di bufferizzare le cose per te. Ma aumentare la dimensione del blocco significa che dddeve usare molta più memoria e potrebbe essere controproducente se si copia su una rete a causa della frammentazione dei pacchetti.

Per quanto riguarda il recupero dei dati, è possibile recuperare più dati da un disco rigido guasto se si utilizzano blocchi di dimensioni inferiori; questo è ciò che programmi come dd-rescuefanno automaticamente: leggono inizialmente blocchi di grandi dimensioni, ma se un blocco fallisce lo rileggono con blocchi di dimensioni inferiori. ddnon lo farà, fallirà semplicemente l'intero blocco.


2
Prestazioni in particolare; scrivere un'immagine di partizione su una scheda SD, ad esempio, usando dd bs=4m iflag=fullblockvs dd bs=1111e notare le velocità di dati sostanzialmente più alte che la prima ti darà. Questo perché il primo si allinea con le dimensioni dei blocchi naturali sulla scheda SD, mentre il secondo richiede al controller SD di fare molta lettura, copia e riflashing per scrivere blocchi fisici parziali. L'importanza di fullblocknon dovrebbe essere sottovalutata, tra l'altro, come senza di essa, bsè solo una lettura massima e parziale potrebbe portare a persistenti disallineamenti successivi.
Jason C

6

C'è un po 'di culto delle merci in giro dd. Inizialmente, c'erano due bug cpche causavano problemi: individuava erroneamente i file come sparsi quando veniva riportato con una dimensione di blocco diversa da 512 (Linux utilizzava una dimensione di blocco di 1024) e non cancellava i blocchi vuoti dalla destinazione durante la copia da un file sparso su un dispositivo a blocchi.

Puoi trovare alcuni riferimenti a questo nei primi archivi della mailing list di Linux .

Quindi le persone si sono abituate a trovare il modo corretto di gestire le immagini del disco, e cp è caduto a lato. E poiché dd utilizza una dimensione di blocco predefinita di 512, è lento (più lento di cp sui sistemi moderni). Ma non è ovvio quale dimensione del blocco dovresti usare. Probabilmente nel tuo caso qualcuno ha letto che il 2048 è la dimensione del blocco "naturale" per un CD-ROM (vale a dire, i CD-ROM sono divisi in settori di 2.352 byte contenenti 2.048 byte di dati insieme a informazioni di correzione degli errori) e ha deciso che questo è la dimensione "giusta" da usare con dd, quando in effetti si otterrebbero probabilmente risultati più rapidi se si utilizzasse una dimensione di blocco (moderatamente) più grande. In effetti, GNU cp usa una dimensione di blocco predefinita di 64k per questo motivo.

tl; dr: cp /dev/dvd foobar.iso dovrebbe funzionare bene. La dimensione del blocco predefinita ddè 512. L'unico effetto che rimane da solo è probabile nella maggior parte delle circostanze moderne è quello di rallentare il processo di copia.


potrebbe essere cambiato, comunque GNU cp usa 128k di blocco di default (non 64k), vedi eklitzke.org/efficient-file-copying-on-linux
apurkrt

5

Cambiare la dimensione del blocco è un buon modo per cambiare quanto viene bufferizzato o letto / scritto alla volta.

Non riguarda davvero se si tratta di un dispositivo a blocchi reale o di un dispositivo infinito / virtuale. Si tratta di quanto vuoi archiviare in memoria prima dddi scriverlo. bs=imposta sia ibs=(quanti dati vengono letti alla volta) sia obs=(quanti dati vengono scritti alla volta). Maggiore è il obs=numero di iterazioni ibs=richieste prima di disporre di dati sufficienti per ddiniziare a scrivere sulla destinazione.

count=non dipende inoltre da nient'altro che da ciò che si desidera fare. Controlla quanti "blocchi" (misurati da ibs=) saranno necessari per ddconsiderare il suo lavoro come fatto.


Nota Stephens punta a ddcopiare blocchi parziali - non è sempre bs * count.
Drav Sloan,

Si noti che su alcuni sistemi unix è necessario leggere un multiplo della dimensione del blocco nativo; ddsenza bs=2048o alcuni multipli di ciò darebbe un errore durante la lettura da un'unità cdrom di un dispositivo a blocchi.
Wurtel

2

L'uso dell'opzione blockize su ddspecifica in modo efficace quanti dati verranno copiati nella memoria dal sottosistema I / O di input prima di tentare di riscrivere nel sottosistema I / O di output. L'output è lo stesso (poiché l'intero disco viene copiato), i blocchi vengono appena letti con le diverse dimensioni specificate (la maggior parte delle ddimplementazioni ha una dimensione di blocco predefinita di 512 byte).

Se si dispone di grandi quantità di memoria di riserva e si aumenta la dimensione del blocco, è possibile leggere in successione blocchi di dati più grandi, bufferizzati e scaricati nella destinazione di output. Una dimensione di blocco inferiore richiede un overhead maggiore in termini di ogni singola ricerca, memset ecc.

La vostra situazione potrebbe essere diversa a seconda di dove la vostra if=e of=sono impostati, e quale hardware si stanno attraversando, se si dispone di poca memoria e così via.


1

I bs = rappresenta la dimensione del blocco di leggere o scrivere. Lasciare il campo intatto o non specificarlo può sembrare fare lo stesso lavoro di copia, ma c'è un fatto nascosto nell'usarlo. Per esempio,

  • Avere 1000000000000000 file con ciascuno di solo 1 ~ 10 kb.
  • Avere un singolo file per 10 GB

Nel primo caso è stato riscontrato che l'utilizzo di blocchi di dimensioni inferiori aumenta la velocità di copia. Mentre in quest'ultimo caso, la dimensione del blocco maggiore è stata un'opzione migliore poiché aumenta la dimensione del settore lasciando un numero inferiore di sector changecomandi, il che di solito si traduce in operazioni di I / O più veloci.

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.