Scopo di ibs/obs/bs in dd

Question

Ho uno script che crea file system in un file su una macchina Linux. Vedo che per creare il file system, usa 'dd' con l'opzione bs = x, legge da/dev/zero e scrive su un file. Penso che in genere specificare ibs/obs/bs sia utile per leggere da dispositivi hardware reali in quanto uno ha vincoli specifici di dimensione del blocco. In questo caso tuttavia, dal momento che legge dal dispositivo virtuale e scrive su un file, non vedo alcun punto dietro l'utilizzo dell'opzione 'bs = x bytes'. La mia comprensione è sbagliata qui? (Nel caso in cui sia utile, questo file system viene utilizzato in seguito per avviare un qemu vm)

Answer 1

La dimensione del blocco è il numero di byte letti e scritti alla volta. Presumibilmente esiste un'opzione count=, che viene specificata in unità della dimensione del blocco. Se è presente un'opzione skip= o seek=, anche queste saranno in unità di dimensioni del blocco. Tuttavia, se stai leggendo e scrivendo un file normale, e non ci sono errori del disco, la dimensione del blocco non è importante purché sia ​​possibile ridimensionarli di conseguenza e siano ancora interi. Tuttavia alcune dimensioni potrebbero essere più efficienti di altre.

Answer 2

Per la lettura da/dev/zero, non importa. ibs/obs/bs specifica quanti byte saranno letti alla volta. È utile scegliere un numero in base al modo in cui i byte vengono letti/scritti nel sistema operativo. Ad esempio, Linux di solito legge da un disco rigido in blocchi da 4096 byte. Se hai almeno qualche idea su come l'hardware sottostante legge/scrive, potrebbe essere una buona idea specificare ibs/obs/bs. A proposito, se si specifica bs, sovrascriverà qualsiasi cosa si specifichi per ibs e obs.

Answer 3

Per comprendere le dimensioni dei blocchi, è necessario avere familiarità con le unità nastro. Se non sei interessato alle unità a nastro, ad esempio, non pensi di usarne una, puoi tornare a dormire ora.

Ricordate le unità nastro di film negli anni '60, '70, forse anche anni '80? Quelli dove girava la bobina, e così via? Non il tuo Exabyte o anche QIC - nastri da un quarto di pollice - nastri; le tue vecchie unità a nastro da mezzo pollice? Su quelli, le dimensioni del blocco importavano.

I dati su un nastro sono stati scritti in blocchi. Ogni blocco è stato separato dal successivo da un intervallo tra record.

----+-------+-----+-------+-----+---- 
... | block | IRG | block | IRG | ... 
----+-------+-----+-------+-----+---- 

A seconda dell'hardware e del software dell'unità nastro, c'erano diversi problemi che potevano verificarsi. Ad esempio, se il nastro è stato scritto con una dimensione di blocco di 5120 byte e si legge il nastro con una dimensione di blocco di 512 byte, l'unità nastro potrebbe leggere il primo blocco, restituire 512 byte di esso e quindi scartare il resto dati; la prossima lettura inizierebbe nel prossimo blocco. Viceversa, se il nastro è stato scritto con una dimensione di blocco di 512 byte e hai richiesto blocchi di 5120 byte, otterresti letture brevi; ogni lettura restituirebbe solo 512 byte, e se il tuo software non prestasse attenzione, staresti leggendo spazzatura. C'era anche il problema che l'unità a nastro doveva accelerare per leggere il blocco e quindi rallentare. L'arte ASCII suggerisce che l'IRG fosse più piccolo dei blocchi di dati; non era necessariamente così. E ci è voluto tempo per leggere un blocco, superare l'IRG, riavvolgere all'indietro per arrivare al blocco successivo e ricominciare avanti. E se l'unità nastro non disponeva della memoria per memorizzare i dati, quelli meno costosi non lo erano, allora si potrebbe seriamente compromettere le prestazioni dell'unità nastro.

Storia di guerra: lavoro preparato su una macchina più recente con un'unità a nastro leggermente più moderna. Ho scritto un nastro usando tar senza una dimensione sensibile del blocco (quindi è stato predefinito a 512 byte). Era un bel po 'di software - deve essere stato, oh, meno di 100 MB in totale (molto tempo fa, in altre parole). Il nastro ha scritto bene perché la macchina era abbastanza moderna, e ci sono voluti solo pochi secondi per farlo. Ma, ho dovuto togliere il materiale dal nastro su una macchina con una vecchia unità a nastro, una che non aveva alcun buffer interno.Quindi, ha letto il materiale, 512 byte alla volta, e il rullo ha oscillato in avanti, leggendo un blocco, e poi ha oscillato di nuovo tutto ma forse mezzo pollice, e poi ha letto in avanti per arrivare al blocco successivo, e poi ha dondolato indietro, e ... beh, si vedeva che faceva questo, e dal momento che richiedeva porzioni apprezzabili di un secondo per leggere ogni blocco di 512 byte, il tempo totale impiegato era orrendo. Il mio volo doveva partire ... e avevo bisogno di ottenere anche questi dati. (E 'stato abbastanza tempo fa, e in una terra abbastanza lontana, anche le modifiche all'ultimo minuto ai voli non erano una gran scelta.) Per farla breve, è stato letto - ma se avessi usato un dimensione del blocco sensibile (come 5120 byte invece del valore predefinito di 512), sarei stato fatto molto, molto più veloce e con molto meno pericolo di perdere l'aereo (ma in realtà ho catturato l'aereo, con forse 20 minuti di riserva, nonostante una corsa in taxi attraverso Parigi nell'ora di punta).

Con più unità nastro moderni, c'era abbastanza memoria sul disco per il buffering e ottenere un'unità a nastro per lo streaming - scrivere in modo continuo senza invertire - era fattibile. Una volta usavo una dimensione di blocco come 256 KB per far scorrere i nastri QIC. Non ho fatto molto con le unità a nastro di recente - vediamo, non questo millennio e non molto per alcuni anni prima di quello, neanche; certamente non molto da quando CD e DVD sono diventati i meccanismi di distribuzione del software di scelta (quando non è stato usato il download elettronico).

Ma la dimensione del blocco in realtà aveva importanza ai vecchi tempi. E dd fornito un buon supporto per questo. Si potrebbe anche trasferire i dati da un dispositivo a nastro che è stato scritto con, diciamo, 4 KB blocco ad un altro che si voleva scrivere con, diciamo, 16 blocchi di KB, specificando il (dimensione del blocco d'ingresso) ibs separatamente dal (blocco di uscita obs dimensione). Utile dannatamente!

Inoltre, il parametro count è in termini di (input) dimensione del blocco. È stato utile dire "dd bs=1024 count=1024 if=/dev/zero of=/my/file/of/zeroes" per copiare 1 MB di zeri intorno. O per copiare 1 MB di un file.

L'importanza di dd è notevolmente diminuita; era una parte essenziale dell'armeria per chiunque lavorasse con le unità a nastro da un decennio o più.