dd: Come calcolare la dimensione del blocco ottimale? [chiuso]

Come si calcola la dimensione ottimale del blocco quando si esegue un dd? Ho studiato un po 'e non ho trovato nulla che suggerisca come questo sarebbe stato realizzato.

Ho l'impressione che un blocco più grande si tradurrebbe in un più veloce dd... è vero?

Sto per avere dddue HDD Hitachi identici da 500 gb che funzionano a 7200 rpm su una scatola che esegue un Intel Core i3 con 4 GB di RAM DDR3 1333 mhz, quindi sto cercando di capire quale dimensione del blocco usare. (Avvio Ubuntu 10.10 x86 da un'unità flash e lo eseguo da lì.)

La dimensione ottimale del blocco dipende da vari fattori, incluso il sistema operativo (e la sua versione) e i vari bus e dischi hardware coinvolti. Diversi sistemi Unix-like (incluso Linux e almeno alcune versioni di BSD) definiscono il st_blksizemembro nel struct statche fornisce ciò che il kernel pensa sia la dimensione ottimale del blocco:

#include <sys/stat.h>
#include <stdio.h>

int main(void)
{
    struct stat stats;

    if (!stat("/", &stats))
    {
        printf("%u\n", stats.st_blksize);
    }
}

Il modo migliore potrebbe essere quello di sperimentare: copiare un gigabyte con blocchi di varie dimensioni e tempo. (Ricordarsi di cancellare le cache del buffer del kernel prima di ogni esecuzione :) echo 3 > /proc/sys/vm/drop_caches.

Tuttavia, come regola generale, ho scoperto che una dimensione del blocco abbastanza grande consente di ddfare un buon lavoro e le differenze tra, diciamo, 64 KiB e 1 MiB sono minori, rispetto a 4 KiB contro 64 KiB. (Anche se, ammettiamolo, è passato un po 'di tempo da quando l'ho fatto. Uso un mebibyte per impostazione predefinita ora, o semplicemente lascio ddscegliere la dimensione.)

Come altri hanno già detto, non esiste una dimensione del blocco universalmente corretta; ciò che è ottimale per una situazione o un componente hardware può essere terribilmente inefficiente per un'altra. Inoltre, a seconda dello stato di salute dei dischi, potrebbe essere preferibile utilizzare una dimensione del blocco diversa da quella "ottimale".

Una cosa abbastanza affidabile sull'hardware moderno è che la dimensione del blocco predefinita di 512 byte tende ad essere quasi un ordine di grandezza più lenta di un'alternativa più ottimale. In caso di dubbio, ho scoperto che 64K è un'impostazione predefinita moderna piuttosto solida. Sebbene 64K di solito non sia LA dimensione ottimale del blocco, nella mia esperienza tende ad essere molto più efficiente dell'impostazione predefinita. 64K ha anche una storia piuttosto solida di prestazioni affidabili: puoi trovare un messaggio dalla mailing list Eug-Lug, circa 2002, che consiglia una dimensione del blocco di 64K qui: http://www.mail-archive.com/eug- lug@efn.org/msg12073.html

Per determinare la dimensione ottimale del blocco di output, ho scritto il seguente script che verifica la scrittura di un file di test di 128M con dd in un intervallo di dimensioni di blocco diverse, dal valore predefinito di 512 byte a un massimo di 64M. Attenzione, questo script usa dd internamente, quindi usalo con cautela.

dd_obs_test.sh:

#!/bin/bash

# Since we're dealing with dd, abort if any errors occur
set -e

TEST_FILE=${1:-dd_obs_testfile}
TEST_FILE_EXISTS=0
if [ -e "$TEST_FILE" ]; then TEST_FILE_EXISTS=1; fi
TEST_FILE_SIZE=134217728

if [ $EUID -ne 0 ]; then
  echo "NOTE: Kernel cache will not be cleared between tests without sudo. This will likely cause inaccurate results." 1>&2
fi

# Header
PRINTF_FORMAT="%8s : %s\n"
printf "$PRINTF_FORMAT" 'block size' 'transfer rate'

# Block sizes of 512b 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M 4M 8M 16M 32M 64M
for BLOCK_SIZE in 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864
do
  # Calculate number of segments required to copy
  COUNT=$(($TEST_FILE_SIZE / $BLOCK_SIZE))

  if [ $COUNT -le 0 ]; then
    echo "Block size of $BLOCK_SIZE estimated to require $COUNT blocks, aborting further tests."
    break
  fi

  # Clear kernel cache to ensure more accurate test
  [ $EUID -eq 0 ] && [ -e /proc/sys/vm/drop_caches ] && echo 3 > /proc/sys/vm/drop_caches

  # Create a test file with the specified block size
  DD_RESULT=$(dd if=/dev/zero of=$TEST_FILE bs=$BLOCK_SIZE count=$COUNT conv=fsync 2>&1 1>/dev/null)

  # Extract the transfer rate from dd's STDERR output
  TRANSFER_RATE=$(echo $DD_RESULT | \grep --only-matching -E '[0-9.]+ ([MGk]?B|bytes)/s(ec)?')

  # Clean up the test file if we created one
  if [ $TEST_FILE_EXISTS -ne 0 ]; then rm $TEST_FILE; fi

  # Output the result
  printf "$PRINTF_FORMAT" "$BLOCK_SIZE" "$TRANSFER_RATE"
done

Visualizza su GitHub

Ho testato questo script solo su un sistema Debian (Ubuntu) e su OSX Yosemite, quindi probabilmente ci vorranno alcuni ritocchi per funzionare su altre versioni di Unix.

Per impostazione predefinita, il comando creerà un file di test denominato dd_obs_testfile nella directory corrente. In alternativa, puoi fornire un percorso a un file di test personalizzato fornendo un percorso dopo il nome dello script:

$ ./dd_obs_test.sh /path/to/disk/test_file

L'output dello script è un elenco delle dimensioni dei blocchi testati e delle rispettive velocità di trasferimento in questo modo:

$ ./dd_obs_test.sh
block size : transfer rate
       512 : 11.3 MB/s
      1024 : 22.1 MB/s
      2048 : 42.3 MB/s
      4096 : 75.2 MB/s
      8192 : 90.7 MB/s
     16384 : 101 MB/s
     32768 : 104 MB/s
     65536 : 108 MB/s
    131072 : 113 MB/s
    262144 : 112 MB/s
    524288 : 133 MB/s
   1048576 : 125 MB/s
   2097152 : 113 MB/s
   4194304 : 106 MB/s
   8388608 : 107 MB/s
  16777216 : 110 MB/s
  33554432 : 119 MB/s
  67108864 : 134 MB/s

(Nota: l'unità delle velocità di trasferimento varia in base al sistema operativo)

Per testare la dimensione ottimale del blocco di lettura, potresti usare più o meno lo stesso processo, ma invece di leggere da / dev / zero e scrivere sul disco, dovresti leggere dal disco e scrivere su / dev / null. Uno script per eseguire questa operazione potrebbe essere simile a questo:

dd_ibs_test.sh:

#!/bin/bash

# Since we're dealing with dd, abort if any errors occur
set -e

TEST_FILE=${1:-dd_ibs_testfile}
if [ -e "$TEST_FILE" ]; then TEST_FILE_EXISTS=$?; fi
TEST_FILE_SIZE=134217728

# Exit if file exists
if [ -e $TEST_FILE ]; then
  echo "Test file $TEST_FILE exists, aborting."
  exit 1
fi
TEST_FILE_EXISTS=1

if [ $EUID -ne 0 ]; then
  echo "NOTE: Kernel cache will not be cleared between tests without sudo. This will likely cause inaccurate results." 1>&2
fi

# Create test file
echo 'Generating test file...'
BLOCK_SIZE=65536
COUNT=$(($TEST_FILE_SIZE / $BLOCK_SIZE))
dd if=/dev/urandom of=$TEST_FILE bs=$BLOCK_SIZE count=$COUNT conv=fsync > /dev/null 2>&1

# Header
PRINTF_FORMAT="%8s : %s\n"
printf "$PRINTF_FORMAT" 'block size' 'transfer rate'

# Block sizes of 512b 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M 4M 8M 16M 32M 64M
for BLOCK_SIZE in 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864
do
  # Clear kernel cache to ensure more accurate test
  [ $EUID -eq 0 ] && [ -e /proc/sys/vm/drop_caches ] && echo 3 > /proc/sys/vm/drop_caches

  # Read test file out to /dev/null with specified block size
  DD_RESULT=$(dd if=$TEST_FILE of=/dev/null bs=$BLOCK_SIZE 2>&1 1>/dev/null)

  # Extract transfer rate
  TRANSFER_RATE=$(echo $DD_RESULT | \grep --only-matching -E '[0-9.]+ ([MGk]?B|bytes)/s(ec)?')

  printf "$PRINTF_FORMAT" "$BLOCK_SIZE" "$TRANSFER_RATE"
done

# Clean up the test file if we created one
if [ $TEST_FILE_EXISTS -ne 0 ]; then rm $TEST_FILE; fi

Visualizza su GitHub

Una differenza importante in questo caso è che il file di prova è un file scritto dallo script. Non puntare questo comando su un file esistente o il file esistente verrà sovrascritto con zeri!

Per il mio particolare hardware ho scoperto che 128K era la dimensione del blocco di input più ottimale su un HDD e 32K era la più ottimale su un SSD.

Sebbene questa risposta copra la maggior parte delle mie scoperte, mi sono imbattuto in questa situazione abbastanza volte che ho scritto un post sul blog a riguardo: http://blog.tdg5.com/tuning-dd-block-size/ Puoi trovare più specifiche sui test che ho eseguito lì.

Ho scoperto che la mia dimensione di blocco ottimale è di 8 MB (uguale alla cache del disco?) Avevo bisogno di pulire (alcuni dicono: lavare) lo spazio vuoto su un disco prima di creare un'immagine compressa di esso. Ero solito:

cd /media/DiskToWash/
dd if=/dev/zero of=zero bs=8M; rm zero

Ho sperimentato valori da 4K a 100M.

Dopo aver lasciato girare dd per un po ', l'ho ucciso (Ctlr + C) e ho letto l'output:

36+0 records in
36+0 records out
301989888 bytes (302 MB) copied, 15.8341 s, 19.1 MB/s

Poiché dd mostra la velocità di input / output (19,1 MB / s in questo caso), è facile vedere se il valore che hai scelto ha un rendimento migliore del precedente o peggiore.

I miei punteggi:

bs=   I/O rate
---------------
4K    13.5 MB/s
64K   18.3 MB/s
8M    19.1 MB/s <--- winner!
10M   19.0 MB/s
20M   18.6 MB/s
100M  18.6 MB/s   

Nota: per verificare qual è la dimensione della cache / buffer del disco, puoi utilizzare sudo hdparm -i /dev/sda

Questo dipende totalmente dal sistema. Dovresti sperimentare per trovare la soluzione ottimale. Prova a iniziare con bs=8388608. (Poiché gli HDD Hitachi sembrano avere 8 MB di cache.)

• per prestazioni migliori, utilizzare la dimensione di blocco più grande che la RAM può contenere (invierà meno chiamate I / O al sistema operativo)
• per una migliore accuratezza e ripristino dei dati, impostare la dimensione del blocco sulla dimensione del settore nativo dell'input

Poiché dd copia i dati con l'opzione conv = noerror, sync, qualsiasi errore riscontrato comporterà la sostituzione del resto del blocco con zero byte. Blocchi di dimensioni maggiori verranno copiati più rapidamente, ma ogni volta che si verifica un errore, il resto del blocco viene ignorato.

fonte