C'è un modo per determinare il valore ottimale per il parametro bs su dd?

A volte ho visto commenti online sulla falsariga di "assicurati di impostare 'bs =' perché il valore predefinito richiederà troppo tempo" e le mie esperienze estremamente non scientifiche di "beh, che sembra richiedere più tempo di quello tempo della scorsa settimana "sembra confermarlo. Quindi ogni volta che utilizzo 'dd' (in genere nell'intervallo 1-2 GB) mi assicuro di specificare il parametro bytes. Circa la metà delle volte utilizzo il valore specificato in qualsiasi guida online da cui sto copiando; il resto del tempo sceglierò un numero che ha senso dall'elenco 'fdisk -l' per quello che presumo sia il supporto più lento (ad esempio la scheda SD su cui sto scrivendo).

Per una determinata situazione (tipo di supporto, dimensioni del bus o qualsiasi altra cosa importante), c'è un modo per determinare un valore "migliore"? È facile da determinare? In caso contrario, c'è un modo semplice per ottenere il 90-95% del percorso lì? Oppure "scegli qualcosa di più grande di 512" è la risposta corretta?

Ho pensato di provare l'esperimento da solo, ma (oltre a essere un sacco di lavoro) non sono sicuro di quali fattori influenzino la risposta, quindi non so come progettare un buon esperimento.

ddrisale a quando era necessario tradurre vecchi nastri mainframe IBM e la dimensione del blocco doveva corrispondere a quella utilizzata per scrivere il nastro o i blocchi di dati sarebbero stati saltati o troncati. (I nastri a 9 tracce erano pignoli. Sii contento che siano morti da tempo.) Al giorno d'oggi, la dimensione del blocco dovrebbe essere un multiplo della dimensione del settore del dispositivo (di solito 4KB, ma su dischi molto recenti potrebbe essere molto più grande e su pollice molto piccolo le unità possono essere più piccole, ma 4KB è una via di mezzo ragionevole a prescindere) e maggiore è il migliore per le prestazioni. Uso spesso blocchi da 1 MB con dischi rigidi. (Abbiamo molta più memoria da gettare anche in questi giorni.)

C'è solo un modo per determinare la dimensione ottimale del blocco, e questo è un punto di riferimento. Ho appena fatto un rapido benchmark. La macchina di prova è un PC con Debian GNU / Linux, con kernel 2.6.32 e coreutils 8.5. Entrambi i filesystem coinvolti sono ext3 su volumi LVM su una partizione del disco rigido. Il file sorgente è 2 GB (2040000kB per la precisione). La memorizzazione nella cache e il buffering sono abilitati. Prima di ogni esecuzione, ho svuotato la cache con sync; echo 1 >|/proc/sys/vm/drop_caches. I tempi di esecuzione non includono un finale syncper svuotare i buffer; la finale syncprende l'ordine di 1 secondo. Le sameesecuzioni erano copie sullo stesso filesystem; le diffesecuzioni erano copie su un filesystem su un altro disco rigido. Per coerenza, i tempi riportati sono i tempi dell'orologio da parete ottenuti con iltimeutilità, in pochi secondi. Ho eseguito ogni comando una sola volta, quindi non so quanta varianza ci sia nei tempi.

             same   diff
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

Conclusione: una grande dimensione del blocco (diversi megabyte) aiuta, ma non in modo drammatico (molto meno di quanto mi aspettassi per le copie della stessa unità). E cate cpnon esibirti così male. Con questi numeri, non trovo dddegno di preoccuparsi. Vai con cat!

Concordo con il geekosaur che la dimensione dovrebbe essere un multiplo della dimensione del blocco, che spesso è 4K.

Se vuoi trovare la dimensione del blocco stat -c "%o" filenameè probabilmente l'opzione più semplice.

Ma dimmi di dd bs=4Ksì, significa che lo fa read(4096); write(4096); read(4096); write(4096)...

Ogni chiamata di sistema comporta un cambio di contesto, che comporta un certo sovraccarico e, a seconda dello scheduler I / O, le letture con scritture intervallate potrebbero causare molte ricerche sul disco. (Probabilmente non è un grosso problema con lo scheduler di Linux, ma comunque qualcosa a cui pensare.)

Quindi, se lo fai bs=8K, permetti al disco di leggere due blocchi alla volta, che sono probabilmente vicini tra loro sul disco, prima di cercare altrove di scrivere (o di servire l'I / O per un altro processo).

Secondo quella logica, bs=16Kè ancora meglio, ecc.

Quindi quello che mi piacerebbe sapere è se esiste un limite superiore in cui le prestazioni iniziano a peggiorare o se è limitato solo dalla memoria.

Come dice Gilles, puoi determinare il parametro ottimale per l' opzione bs da dd mediante benchmarking. Questo, tuttavia, pone la domanda: come si può comodamente confrontare questo parametro?

La mia risposta provvisoria a questa domanda è: usa dd-opt , l'utilità su cui ho recentemente iniziato a lavorare per risolvere esattamente questo problema :)

Ho ottimizzato per il lettore sdcard usb2.0 che sembra funzionare al meglio bs=10M. Ho provato 4k, fino a 16M, dopo 8-10M nessun miglioramento. Puoi vedere come la misurazione della velocità di trasferimento si degrada ... molto probabilmente a causa del caricamento dei buffer sul dispositivo, quindi in attesa del trasferimento del dispositivo sul supporto effettivo.

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s